I am trying to better understand how the App-Code folder operates, and in particular I am curious how new objects that a new class in the App-Code folder are included in the current AppDomain. Is a second, temporary AppDomain created in the same manner as when I compile new objects with the CodeDom?
In many ways the capability of moving new classes / objects into a Web Application is very compelling. Rob Connery's MVC Storefront is a good illustration. If you have used the App-code folder to deploy new functionality were there any trade-offs or gotchas that should be considered?
UPDATE:
I found an article in CoDe Magazine with this interesting passage:
Your application-specific code can go
inline of the ASPX page or control, it
can go into a CodeBeside partial
class, or you can create completely
autonomous classes in the APP_CODE
folder. The APP_CODE folder is a
special folder in an ASP.NET 2.0
project and any non-page or
control-related source code in your
Web project must go into this folder.
ASP.NET treats the content of APP_CODE
like a library project and compiles
the content into a separate assembly.
This assembly is then referenced by
all of the page or directory-level
assemblies that ASP.NET creates from
your ASPX/ASCX pages that use any of
the classes defined in APP_CODE.
My question still stands - is a second AppDomain created that supports this libary, and if so are the impacts on performance minimal?
I don't know the details, but it will certainly be in different dynamic assemblies. A class can't be in another AppDomain. Only an instance of a class can be in another AppDomain, and then it's really a hassle to access from another AppDomain (only through remoting)
Related
I want to create classes that can be inherited by other classes to use along my project.
i.e. i want to create a separate class for each Mail method, each class will implement differently the Compose method, and more Mail classes will be created in the future.
My question is - Where should I create these classes/interfaces? in the App_Code ?
I would suggest creating a separate assembly and include that assembly as a reference in your Web Project. That will enable you to write independent test cases against your classes / interfaces.
Other than user controls you can store source files in App_Code. In your case you can store Interfaces/classes in App_Code. You can have multiple folders for group of class/interfaces inside the AppCode.
AppCode
You can store source code in the App_Code folder, and it will be
automatically compiled at run time. The resulting assembly is
accessible to any other code in the Web application. The App_Code
folder therefore works much like the Bin folder, except that you can
store source code in it instead of compiled code. The App_Code folder
and its special status in an ASP.NET Web application makes it possible
to create custom classes and other source-code-only files and use them
in your Web application without having to compile them independently.
Edit: You may see this discuss: How to organize ASP.NET app_code folder?
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.
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 ;-)
I would like to start pulling out pages that meet certain criteria from the main assembly into a referenced assembly, while we transition the project to MVC.
Alternatively, I could create a fresh MVC project and just reference this assembly's pages/static content if that is possible. How would I go about it either way?
I'm thinking legacy .js,.css static content.
Also aspx, aspx.cs, ascx.cs, ascx.designer.cs, aspx.designer.cs and ascxpages that are functionally ready to be obsoleted for mvc .cshtml versions.
Oh and ESPECIALLY all references to 3rd party User controls.
Not 100% confident this will help, but in short I would ask:
Why don't you pull the logic of the Handler, WebPage into another class library and in aspx/ahsx header set the referencing class to the class library's namespace. If the class library is in your bin (referenced) I don't see a problem.
With static content, I don't see why you would move it to another assembly as it is not in an assembly to start with (served by IIS). If you must move it you will need to write a proxy class to make the needed io to read the file(s) and send to the response stream.
We have a solution with multiple web projects, and there are some pages that should be present in several of them. So we'd need some sort of a shared project which contains aspx files, and which can be referenced by other web projects.
Now there are a few implementations out there:
One implementation described by ScottGu which involves building the shared project, and than copying the output aspx into the host project, and referencing the dll of the aspx. This method has the disadvantage that if the apsx gets modified it must been recopied.
Another option, based on David Ebbo's post would be to convert the aspx into ascx-es which can be referenced as custom controls, and than include those custom-control-aspx-es into the host project inside of some placeholder pages. But my concerns are: can all apsx pages transformed into an ascx? I mean there's no Page.LoadComplete event in user controls for example.
And yet another option is to use virtual directories that map into the shared webproject, as described in a Microsoft KB article. The problem again with this method is that the shared aspx-es must be in predefined directories(that is the virtual directory).
If the name of virtual directory overlaps a physical directory, the virtual overrides it and no pages from the latter can be used.
Is it perhaps possible to merge these two together?
Any thoughts? Thanks in advance
P.S. How about debugging the shared pages?
I solved this problem by making shared Class Library that contains .ascx controls. Have not found real difficulties when converting from .aspx pages to .ascx controls. Found this sample by ScottGu really simple and good place to start. http://webproject.scottgu.com/CSharp/usercontrols/usercontrols.aspx.
The solution which we are using is ScottGu's method, which involves copying the aspx files from the shared project to the host projects.
A post build event in the shared project copies the files to their place, like this
xcopy "$(ProjectDir)Forms\Techs\AddEditTech.aspx" "$(SolutionDir)..\TTAdmin\Forms\Companies" /i /d /y
if errorlevel 1 goto BuildEventFailed
xcopy ....
goto BuildEventOK
:BuildEventFailed
echo POSTBUILDSTEP for $(ProjectName) FAILED
exit 1
:BuildEventOK
echo POSTBUILDSTEP for $(ProjectName) COMPLETED OK
Have you thought about baseclassing the functionality into classes that inherit from Page and place those classes in the shared DLL. All implementing applications could then implement that page by inheriting from it and still be able to change functionality assuming the base classes provide overridable methods. I've had pretty good success with this when I had a lot of pages that were used in many applications and all had the same code. Just a possibility.
Have you considered service oriented development? Build the functionality into services you can share. Build your functionality like widgets. This way you only have one codebase but you can use it in multiple sites.
Think outside the (.Net box)
I'm onto a real head scratcher here ... and it appears to be one of the more frustrating topics of ASP.NET.
I've got an assembly that implements a-lot of custom Linq stuff, which at it's core has zero web functionality. I have an additional assembly that extends this assembly with web specific behaviour.
The web specific behaviour comes with a couple of user controls marked up inside ASCX templated UserControls.
I'm having trouble putting a nice finish on this assembly so that it is simple to redeploy for use in other applications. Let me run through what I've tried so far:
Copied the ASCX files to the consuming web application using build events; far from ideal and quite a deployment nightmare.
Implemented a custom VirtualPathProvider and embedded the ASCX templates within the assembly as embedded resources. Unfortunately when using the Register directive in the consuming application it creates the designer declaration as a UserControl, where I would require a declaration of the actual control type; unforeseen (typically) and undesirable.
Created a Web Deployment Project to compile the UserControls, but the compiled user controls then become part of another assembly, and no longer descend from the class definitions in my web assembly--the assembly needs to instantiate them dependent on the request context.
So number 1 is just crap, number 2 doesn't give me the type support I desire and number 3 I think I'm about to produce a reasonable solution with:
Lump all non-control classes into the App_Code folder, prepare a factory class that will construct an object of the desired control type using reflection and the expectation that the type being reflected will be present in the deployment output (hopefully guaranteed by the presence of the ClassName attribute in the Control directive).
Theres also always the other option of rewriting the ASCX controls into custom controls, but just don't have the resources to consider it at the moment, and we've got no expertise in doing that, and they work fine as UserControls.
Am I missing something obvious, something maybe much simpler, or is this just purposefully difficult? I've read stories of the ASP.NET compilation process being very unfortunate in it's design on my travels across this topic.
Well I think I've done it ... by being mindful of a few of a few annoying pitfalls with my last approach, I recommend the following when compiling ASCX user controls in a Web Application Project using a Web Deployment Project:
Avoid putting classes in App_Code unless they're standalone or helper classes, ASP.NET treats this as a speshul folder, the meaning of which is lost on me, mayhem, confusion and chaos follows. Code in this folder does get output in the Web Deployment Project, though.
Pay close attention to your assembly names, their root namespaces and deployment output assembly name- you'll get access is denied errors if you have any naming conflicts during the aspnet_merge process.
Ultimately you'll most likely end up deploying 2 assemblies, I tried to create only one but the deployment output was still pointing to type definitions in the source assembly. This isn't a problem if you don't have any other types in your Web Application Project--I have so it was a problem for me. In my case, my final output was:
<Organisation>.<TechnologyName>.Web.DLL - Compiled Web Application Assembly (containing the ASCX templates)
<Organisation>.<TechnologyName>.Web.UI.DLL - ASP.NET Compiled UserControl assembly, created by Web Deployment Project
Clean often, and check that the Web Application Project's bin and obj paths are cleared of any previous junk built when you perhaps hadn't finalised your namespace or assembly naming scheme--the Web Deployment Project will be quite keen to include these, causing a fine mess.
Check your imported namespaces, the ASP.NET compiler likes to refer to the Import directive in the ASCX template, and it also considers imported namespaces present in web.config's <configuration><system.web><pages><namespaces> element, tweak if you get unknown definitions appearing during the deployment process.
Have some patience spare, it's quite tricky! But you do get some nice re distributable UserControls at the end of it!
Phew!