3

In a dynamically compiled ASP.NET Website project, can the assembly for the App_Code folder be explicitly named?

For example, under regular circumstances when I run an ASP.NET website the assembly name generated into the Temporary ASP.NET Files\ folder is partially randomized like App_Code.neizakfo.dll where neizakfo is the portion that can differ. Can I explicitly provide a name for the assembly like App_Code_Web1.dll?

Clarification

By business requirements, the website cannot be precompiled/deployed. Therefore I'm seeking a solution in context of the Temporary ASP.NET Files folder and dynamically compiled assemblies as noted above.

Background:
I came across this question while looking for a way to perform dynamic type instantiation on a class in the App_Code folder of a website using an assembly-qualified name stored in configuration, but instantiated from the web page, thus crossing an assembly boundary. Because the web page and app_code code are compiled into two different assemblies by default, the Type.GetType(..) method's default behaviour of searching for the Type name either in the current executing assembly (the web page) or in mscorlib doesn't suffice for picking any Type from the App_Code assembly. Being randomized, the app_code assembly name is not known for me to include in the assembly-qualified string.

I can put the data Type in a class library (because that does have an predefined/exact name) to get rid of this problem, however I'd like to know how to do this inside the website itself without creating a class library project for the purpose.

John K
  • 28,441
  • 31
  • 139
  • 229
  • 1
    Sort of. See http://msdn.microsoft.com/en-us/library/bb398860.aspx#PreCompilingToFixedNameAssemblies. I much prefer Web Applications as this behaviour is much better defined. What you are looking to do is trivial in a Web Application project. – dash Mar 01 '12 at 17:08

1 Answers1

4

You can sort of do this in a WebSite project.

There's an MSDN article on using the -fixednames flag when compiling the project.

This effectively creates an assembly for each page - default.aspx.dll. However, this is only marginally more useful to you as you still need to know the name of the control or page you are looking for when you are loading - so you have to ensure your types and naming is consistent. It should, however, respect the name of the classes in app_code so this may work for you.

One other thing you could do is move all of the code in app_code out into it's own assembly, and then add that as a project reference. That would also simplify this problem.

Lastly, you could enumerate all of the dll's in the bin directory, and search each one for the type you are looking for. As this is fairly expensive, do it once, and cache the result somewhere so you don't keep doing it everytime you look that type up. This is probably the worst solution.

This is trivial to do in a WebApplication project, but I assume you are stuck with the WebSite one?

EDIT: As an update for the comments; if I use the Publish Web Tool, then all of the code in app_code goes in the bin directory in a dll called App_Code.dll - this behaviour does not change even if I use fixed naming (all fixed naming effects the naming of the dll's for each page, usercontrol). If I use ILSpy on this file, I can see my classes in there. So I know the name of the assembly, and it's location - I should be able to get at the types in it with minimal effort. I wonder why I'm seeing different behavior to you!

I created a simple class called "Person" with an Id and Name, put it in App_Code, compiled the site, and then ran the following code:

  Type myType = Assembly.LoadFrom(Server.MapPath("~/bin/App_Code.dll")).GetType("Person", true);
  Response.Write(myType.ToString());

It wrote out "Person", as expected.

Further Edit

The penny drops! If I then do:

  object myObject= Activator.CreateInstance("App_Code.dll", "Person");

And try to cast myObject to person, I get the following message:

The type 'Person' exists in both 'App_Code.dll' and 'App_Code.jydjsaaa.dll'

So it's time to be devious.

in Global.asax, on Application_OnStart, do the following:

Application["App_Code_Assembly"] = Assembly.GetAssembly(typeof(Person));

In my test default page, I then did:

  Assembly app_Code = Application["App_Code_Assembly"] as Assembly;
  Response.Write(app_Code.FullName);

Which gave me the randomly named app_code it is actually running with in Temporary ASP.Net Files.

This is why I hate Web Site Projects ;-)

dash
  • 89,546
  • 4
  • 51
  • 71
  • I noted in Background info that a distinct assembly is possible as you suggested but am trying to see if I can do without. Not all dlls are in the website's bin folder so I'm hesitant to enumerate over ASP.NET Temp files but you're right that caching the info for later use is an optimized possibility. In your first suggestion, even if web pages have known assembly names, I'm still unable to dynamically load an app_code class (is not in a web page) by string name due to same circumstances - can you provide more clarity about the fixed name suggestion, I might not understand effect on app_code. – John K Mar 01 '12 at 17:59
  • I was just building my answer out for completeness - I believe that putting the code into a separate assembly is the right answer in this instance, but am very interested by what you are trying to do (great question!). It's been a while since I used a web site project (I dislike them for many reasons) but I'll go take a look at one of our early projects as I'm sure I tried something along these lines there. – dash Mar 01 '12 at 18:13
  • @JohnK I've updated my answer with an experiment I just tried. – dash Mar 01 '12 at 18:33
  • I see. That makes sense in context of VS publishing features, there is a very specific compiled output that works much like any compiled app. In my case the website is copied and we don't have the option to precompile/publish because of a requirement for source to be updatable and the website to dynamically compile. I'm working with the `Temporary ASP.NET Files` folder into which assemblies are dynamically compiled and named. I'll update my question with this clarifiation. You're right the best solution in my case is a separate class library. – John K Mar 01 '12 at 20:00
  • I like your test code and answers. They are definitely worthwhile to have here to round out the context of this question and provide alternate options. – John K Mar 01 '12 at 20:06