What are the advantages, if there are any, of using a separate DLL in the BIN folder instead of adding your classes to the App_Code folder. Is there a method preferred?
Take a look at this article Web Application Projects versus Web Site Projects on MSDN.
You can also read anserws from this question
Related
I am migrating my web site to web application and not sure where to put app_code files? I have moved the whole app_code folder to web application but while compiling web app I get error that classes are not found.
I think once an Web Application, the App_Code folder is relatively useless...as in, it doesn't have its special meaning that it has within a WebSite project. So there's nothing stopping you still having a folder called App_Code and putting your classes (and whatever other files) in there.
It may make more sense to put the files within folders and namespace the classes with relevance logical groupings (helper classes, business rules, data access, whatever) or perhaps move the classes into a separate Windows Class Library project (DLL) which your web application references...
I just found that I must mark files inside app_code as compile and everything will work.
A couple of questions:
Is App_WebReferences for WCF schema files? Should this not be App_ServiceReferences?
Also, what is dynamic compilation in ASP.NET?
Thanks
From MSDN:
App_WebReferences folder Contains
files used to create a reference to a
Web service (in the same project or
external to the project), including
.disco and .wsdl files
There's no special folder in ASP.NET called App_ServiceReferences.
As far as dynamic compilation is concerned you may take a look at this article which explains it very good.
I am relatively new to ASP.NET programming (but not programming in general), and I have been looking through a project that has been handed off to me. Within this project, there is a bin directory which contains a slew of various DLL files.
Then, in the web.conf file, inside the assemblies structure (within the XML), there is a slew of other assemblies being added.
I've done a search on both SO and through Google in general, and I am still struggling over what the difference is between the two. Is one way "better" than the other? Any clarification that can be provided would be most appreciated.
Thanks.
There are several ways to reference assemblies (DLLs, usually) in an ASP.NET application:
Add the DLL to your application's "bin" directory. This creates an implicit reference in every code file and ASPX file in your application to that DLL. This means that code inside an ASPX file or inside a CS file in App_Code can use the types in that DLL.
Add a reference to the DLL in the <assemblies> section in web.config. See MSDN for details on the syntax. There are generally multiple web.config files that apply to a particular web application. The application itself can have several web.config files (for example, a web.config in a particular folder might add its own references). There is also a global web.config (or machine.config) that has references available to all ASP.NET applications on the computer.
Use the <%# Assembly Name="" %> directive in a particular ASPX (or ASCX or MASTER) file. See MSDN for details on the syntax.
The references in a given file in an ASP.NET application is a combination of the applicable items above.
The reason you have to reference assemblies is that ASPX files (much like CS and VB files themselves) eventually get compiled by either the C# or VB compiler. In order for those compilers to know what types you want to use they need to know which assemblies contain those types.
The bin directory is a copy of all the dll's that are built and referenced by your project. When the web application is running, it looks in the bin directory for the physical dll's it needs to execute the web application.
The title pretty much says it all.
Given a web site project in VS2008 named FooDLL, I would like to be able to specify the name of the assembly that VS2008 spits out when I click "Publish Web Site". I am using the "use fixed naming and single page assemblies" option, so the resulting DLL is consistently named.
However, I would much rather be able to specify that the DLL is named something like FooDLL.dll (or just Foo.dll, whatever) than be stuck with the ugliness of App_Web_foo.ascx.cdcab7d2.dll.
Am I stuck since Web Sites don't have .project files (e.g. aren't projects)?
Not to continue the pattern of answering my own questions, but here it is anyway:
All I had to do was add a Web Deployment Project for the web site containing my user control. Though you can't specify the assembly name when building/publishing a web site, you can do this through the web deployment project. It's basically just a nice GUI for an msbuild project file... for a web site. Hooray for hacking a .project file onto a web site!
You could just compile your code as a class library project, then drop it into the Bin directory of your website.
I believe you are.
I am unaware of any benefits to using a web site project and while the benefits of using a web application project are minor, they exist. Create web application projects from now on.
ASP.NET Merge Tool (Aspnet_merge.exe) is your way to go.
It merge your web assemblies into one assembly for the whole Web site.
more information:
http://msdn.microsoft.com/en-us/library/bb397866.aspx
Can I somehow utilize the App_code folder in a web application project to compile code on the fly? It'd be great for plugins. Recently Rob Conery demonstrated its use in his talk at MIX 09 in a ASP.NET MVC app. I tried to do the same in a web app but I can't access the classes under App_Code from anywhere else. But if Rob was able to do it in an MVC app, it should be doable in a web application too. After all ASP.NET MVC IS a ASP.NET Web Application under the covers.
If you add a code file to the App_Code folder, it should be compiled and available from a code-behind file for a control, or another code file in the App_Code file.
I don't think you'll be able to access it directly from a compiled assembly, since the compiler won't be able to find that reference at compile time.
You'll also need to be aware that App_Code is compiled into a different assembly than your code-behind code, so you can't access internal code across the different assemblies.