Unknown server tag 'csla:CslaDataSource'.

Diz posted on Monday, December 11, 2006

Hi,

I'm working in VS 2005.   I've got a solution containing my BO library, and a Win UI and a Web UI.   I'm at the stage of trying to hook up the biz objects to the Web UI. 

I've used the same BO library in a simple ASP.net only project (no solution, no project references) successfully, so I assume there's no problem with the BO library.

The web.config is stolen directly from the PT Web app and includes this:

    <pages>
      <controls>
        <add tagPrefix="csla" namespace="Csla.Web" assembly="Csla"/>
      </controls>     
    </pages>

I've got Intellisense when I go to create a  csla:CslaDataSource tag, so VS2k5 knows about the controls, at least somewhat.    But when I try to run the web app, I get the uknown server tag error. 

I'm using the built in development web server, and have set it to a fixed port.    The only thing different between this and my test web project is that this solution contains my BO library project, as well as a couple of other projects.  I don't see how that could cause this, but it's the only theory I have so far. 

Has anyone seen any behavior like this?
Thanks!

david.wendelken replied on Monday, December 11, 2006

Don't use the built-in VS 2005 web server.  Force your project to use IIS.  

Also, putting the BO Library source code in the same solution can cause difficulties.  It has to do with some truly bizarre practices by the VS 2005 web team and shadow directories.  You might notice the problem when you add classes to the BO Library after you've already compiled and run the web site.   There are various threads touching on how to get around this when it happens.  I usually am just really careful to build all the objects that I'm going to need first. :)

Diz replied on Wednesday, December 13, 2006

Thanks for your input David. 

I've narrowed this down to the fact that the files are sitting on a network share.  We use Clear Case here, and it's all in a Dynamic View.    If I copy the solution to a local drive and fire it up, it runs fine.  Same code on a network share fails. 

.net has been configured for full trust on the intranet zone. 

So it's not a CSLA thing, anyway, it seems.
Thanks again!

guyroch replied on Sunday, December 24, 2006

Have you tired signing your assemblies?

Programs that run on the CLR use something called code access security (CAS). CAS is different from traditional security systems in that it assigns trust to code rather than users. To do this, the security system gathers a set of evidence about every assembly it loads. This evidence is then compared against the security policy, and a permission grant is generated.

One of the pieces of evidence that the security system gathers is the security zone that the code is running from. When you run the code from your local machine, this will be the MyComputer zone, but when you run it off of a server, or even a network share mapped to a drive on your machine, it will be the LocalIntranet zone.

By default any code that is run from the MyComputer zone will get a permission set of FullTrust (unrestricted permission to do anything it pleases). However, by default, there is a more restrictive permission set given to LocalIntranet assemblies.

The way to make an application that works from the MyComputer zone work from the LocalIntranet zone is to give the assemblies in your application a strong name, and modify the security policy to trust this strong name. Hence the need for a key.

Hope this helps

jspurlin replied on Sunday, December 24, 2006

Do you have this in your web config?

<pages pageBaseType="BasePage">
            <controls>
                <add tagPrefix="csla" namespace="Csla.Web" assembly="Csla"/>
            </controls>
            <namespaces>
                <clear/>
                <add namespace="System"/>
                <add namespace="YourAssembly.Namespaces"

It is a great way to tell ASP.NET to look for controls and import namespaces at the page level.

Jurjen replied on Sunday, December 24, 2006

Hi Diz,

I'm facing exactly the same problem and was wondering if you had found the solution and would be willing to share ...

Jurjen.

Diz replied on Tuesday, December 26, 2006

Hi Jurjen,

I think for me it was some security thing, or some strange side-effect of developing over a network share in a mixed environment. 

I moved the code to a local drive, and everything works fine.  Changed from a Clear Case Dynamic view (files sit on a mapped network share on a *nix server) to a Snapshot view (files sit on a drive on my dev machine, similar to the approach VSS uses).  That's the only change I made.

Are you developing over/on a network share?
Tom

Jurjen replied on Wednesday, December 27, 2006

Tom,

I reference my assemblies over a network share, I've done this in various projects and it has always worked well for me. Can't say why it doesn't work now (I've added a Csla tab to the toolbox and added the DataSource control to it and now I can add it. But adding it by type <csla:data... doesn't get recognized.

Jurjen.