I am looking for some advice on how what is the best approach to subweb folders and having mutliple bin folders in the WebSite Project model. For adding new pages at a later stage without recompiling the core files of a website and without building a full fledged Plug-in framework api. I am aware of being able to drop in the compiled dlls into the main bin folder and to just copy over the new page files to a sub folder but I am looking for a more organized file/folder approach.
Here is the how it was done with WAP:
Moving the Code-Behind Assemblies/DLLs to a different folder than /BIN with ASP.NET 1.1
Multiple /bin folders in ASP.NET
I should also mention that I see that I can still do it the old way with the website project model by making the adjustment to the config section mentioned here but I was wondering if that has any side affects.
AssemblyBinding in Web Config and XMLNS
Are you trying to copy new DLL's or new sources to your site? Note that for sources, the best place in web sites is the App_Code folder. In there, you can create any arbitrary folder structure that you like, and it will all be built at runtime into an assembly. Then, every page gets a reference to that assembly and is able to use types from there.
Related
In the old asp.net project, there is a published .cs file in one of the folders. When I update the site, I update the .dll files, but this file is never updated. When I delete this .cs, the site does not work. How do I delete this file?
Are you using a asp.net web site applcation to publish, or are you using a asp.net web site?
As a general rule, if you using asp.net web site applcation, then the source code files are NOT required to be up-loaded.
However, you left out one big detail. Where is that cs file? While a asp.net web site will attempt and does pre-compile all code, ONE BIG exception to this rule exists.
That is the folder app_code. That folder is in fact compiled by IIS, and as a result, if that file is in that folder, it will have to be included in your publish.
In fact, when I started using the newer Roslyn compiler (I liked it VERY much for allowing me to have longer free text such as SQL in the code as strings).
However, IIS did not and does not have Roslyn compile by default. And my code was breaking.
So, as a result, I simple create my own folder called MyCode. And you could do the same. Note that each code module (vb.net) or static class for your general shared code routines do have to be marked manually as to compile.
eg this:
So, if your .cs file is in app_code, then you can move it out, drop it into a folder you create, and set the file build action to compile, and of course do not copy.
However, and this is a HUGE big "if". If your deployment model is web site as opposed to web site applcation, then this will not work, since IIS is doing your compile after deployment, as opposed to pre-compiling the code BEFORE deployment.
So, you are in luck if your .cs file is (or was) in app_code, since then as noted, you can move that out of app_code, and in properties set the file to be compiled, but not deployed. This as noted will only work if you deploying as a asp.net web site applcation as opposed to a asp.net web site.
I get some troubles with a DLL reference.
I have MySql.Data.dll in my bin folder. And I added the reference of this dll to my project.
I can well use classes from this dll (like MySqlConnection, MySqlClient, etc) in aspx.cs but i cannot use it in classes from files from App_Code folder !
For all files situated in App_Code folder (my model classes) , the using MySql.Data; doesn't work. While it works in aspx.cs files.
As you know, there are two types of projects that you can use to create a website in Visual Studio. The App_Code folder works for Web Site projects, but since you stated that you're using a Web Application project, this is causing you problems.
Here's some additional reading on this topic.
In short, I recommend just creating a different (non-built-in) folder to put your random code files in. Name it something like "code", "classes", etc.
After publishing asp.net web site, I got mant ASP_Web_xxxxx.dll.
After deploying these files to production server, how do I know which file to be replaced, if I modify one codebehind or .aspx file and re-publishing the web site?
Thanks.
It sounds like you are running a web site, and not a web application project. A website doesn't have a project file, and therefore doesn't create a single dll. Instead it created a bunch of smaller dlls. You don't have any control over which classes, etc are in which .dll.
When you deploy your web site, you will need to delete all of these dlls and move all of the new ones over. If you don't do this, you could potentially have 2 dlls that contain the same code, and you will run into issues with code being defined twice when you JIT.
If you can, I recommend you migrate your web site to a Web Application Project, so you only have one .dll you need to worry about. There are several tutorials out there including this one for VS2005.
this is likely a naive question, but I want to do this right the first time.
I have a MVC solution which has the following:
Data project - C#
Services project - C#
MVC Web Project - ASP.NET MVC
Test Project
Currently, I am using the MVC2 source as a means to debug my own code. I do not plan on checking that in, but I realize once I go back to the MVC2 DLL, my solution will change.
I'm pretty sure I just shouldn't check in stuff that changes with each build: the bin folder on the Web project, for example.
Is there a list of what not to commit to source control? :)
Exclude the bin folder. Also be on the look out for .user or .suo files. Those file store your own settings and will change from user to user so it shouldn't be in source control.
If you're using a database stored in the App_Data folder, be sure to ignore that as well (the database file, not the App_Data folder).
Generally, I exclude the bin and obj folders of every project from source control. I can't remember needing to do anything else.
do you use ankhsvn?
i think ankhsvn automatically exclueds directories which are not needed in subversion
cheers
I'm using a Web Deployment Project in Visual Studio 2008 in order to prepare my ASP.NET application (ASP.NET web application, not ASP.NET web site) for being copied to several servers. I have to copy the files on local staging servers, on different servers via FTP and sometimes I have to fetch them from customers' servers.
So, it would be nice to have all files for deployment in a compact form without the necessity of doing a lot of comparing between source and destination. Web deployment projects have this nice feature: compile all your aspx and ascx files into a single (additional) assembly.
I somehow found out how to get rid of aspx placeholder files on the server, now I'd like to know if there is a (maybe self-made) way to get rid of these .compiled files.
From Rick Strahl's blog:
The .Compiled file is a marker file
for each page and control in the Web
site and identifies the class used
inside of the assembly. These files
are not optional as they map the ASPX
pages to the appropriate precompiled
classes in the precompiled assemblies.
If you remove the .Compiled file, the
page that it maps will not be able to
execute and you get a nasty execution
error.
Anybody out there with a creative idea, maybe using a module/handler which intercepts the check against the .compiled files in the bin folder?
The .compile file comes from pre-compiling on deployment. So you basically have 3 options:
Keep the .compiled file
Don't pre-compile and deploy source code
Turn this in to a Web Application instead of a Web Site and compile as an assembly
I have run in to the same problem myself. I actually choose #1 in most cases when dealing with deployment of Web Sites, but on the rare occasion when I know I am going to have to maintain the site for an extended period of time, I take the time to upgrade it to a Web Application.
I don't like the .compiled files either, but nobody gets hurt if they're there. So why bother?
You might want to take a look at Virtual Path Providers (KB how to here) in ASP.NET.
Credit for this suggestion must go to Cheeso and his self answered question here:
Can I get “WAR file” type deployment with ASP.NET?
I don't know about the .compiled files, but you could set up your servers to update their files with subversion instead of manually copying the files when you compile.
So you would compile the files using the Web deployment project (not into a single assembly), put them in a repository you created for this purpose, and on each server, just do an svn update to fetch and compare the files automatically.
I know it's not what you asked for directly, but it may be a path to explore.
Add "Exclude Filter" to your deployment project:
In the Deployment Project.
Right Click on Content Files.
Click on "Exclude Filter".
Add "*.Compiled"
click OK.
and thats it.
I remember at the days when I cant do Web Application with VWD Express, I use nant script to compile the project into a single dll and deploy, that would work (so I dont need the full VS to do dll deployment too), so if you really don't want to mess your project to Web Application, maybe this is a path to check too.
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
If you publish your code as updateable (in publish settings) these files are generated. Uncheck that value and republish. This is an old question I know, but no answers are clearly defined for this here.