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.
Related
i have publish my website. using publish website in vs 2008.
Now i want to update a single file.
So do i need to recompile the whole web-site and upload it to the server again, or i will just publish this single file and upload it to the server.
if i can compile a single file then how to do it, also how to update it to the server?
Depends on whether your web project is a web application project or web site project. If its a web site, then you can just copy your updated file to the server and ASP.NET will recompile it for you.
If your web project is a web application project, and you made changes to the code behind, you'll need to recompile the project, and redeploy the DLL.
Also, if you're just updating an ASPX page (not the code behind, ASPX.cs), you should be able to deploy it without compiling.
If you frequently update your website, I recommend to Check
Use fixed naming and single page assemblies checkbox.
This will generate seperate DLL for each code behind page,
Although you have to compile full project but you can upload only relevant file.
This is very helpful in case if many people are working in single project, everybody can change in their respective .cs file and publish their .cs file's DLL , this will not affect other people's DLL and thus functionlity will not break, unless DLL's or codebehind clashes with each other.
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.
I have an ASMX Web Service that has its code entirely in a code-behind file, so that the entire contents of the .asmx file is:
<%# WebService Language="C#" CodeBehind="~/App_Code/AddressValidation.cs" Class="AddressValidation" %>
On my test machine (Windows XP with IIS 5), I set up a virtual directory just for this ASP.NET 2.0 solution and everything works great. All my code is separated nicely and it just works.
However, when we deployed this solution to our Windows Server 2003 development environment, we noticed that the code only compiled when all of the code was dropped directly into the .asmx file, meaning that the solution didn't work with code-behind. We can't figure out why this is happening.
One thing that's different about our setup in our development environment is that instead of creating a separate virual directory just for this solution, we dropped it into an existing directory that runs a classic ASP application. So here we have a folder with an ASP.NET 2.0 application within a directory that contains a classic ASP application. Granted, everything in the ASP.NET 2.0 application works if all of the code is within the .asmx file and not in code-behind, but we'd really like to know why it's not recognizing the code-behind files and compiling it correctly.
As others have mentioned, it's probably a better practice to build the solution as a "Web Application Project." This way your code will be precompiled to run on the server.
The following solution worked for us: In IIS, navigate to the folder in your website that contains your solution. Right click on the folder and choose Properties. In the Directory tab, under Application Settings, click Create to make the folder into an application (I believe this can also be accomplished simply by making the folder a Virtual Directory). Then, make sure your ASP.NET configuration is set to use ASP.NET Version 2.0. The problem we had was that the larger directory was running under ASP.NET 1.0, so we had to go through this step to have this directory use ASP.NET 2.0.
You may have a difference between a Web Site "project" and a Web Application project. In a web site project, all of the files are compiled dynamically. In a web application project, you have to build the code first.
You should be using Web Application Projects for web services. Use File->New Project and choose the appropriate project type. Then build your project and finally use the Publish command to deploy to IIS.
I'm not sure I can explain why its not working however placing Code behind files in the App_Code folder seems like a dodgy thing to do. App_Code files will get compiled into a single assembly. Hence the code in your code behind will end up in this assembly even though its not intended to.
I would first create a AddressValidation.asmx.cs file in the same folder as the .asmx folder and tweak the CodeBehind attribute of the asmx file. Remove the file from the App_Code folder and place its contents in the new .asmx.cs file.
Check this works in the XP environment then move it the destination server.
I want to update a class library (a single DLL file) in a production web application. This web app is pre-compiled (published). I read an answer on StackOverflow (sorry, can't seem to find it anymore because the Search function does not work very well), that led me to believe that I could just paste the new DLL in the bin folder and it would be picked up without problems (this would cause the WP to recycle, which is fine with me because we do not use InProc session state).
However, when I tried this, my site blows up and gives a FileLoadException saying that the assembly manifest definition does not match the assembly reference. What in the world is this?! Updating the DLL in Visual Studio and re-deploying the entire site works just fine, but it is a huge pain in the rear. What is the point of having a separate DLL if you have to re-deploy the entire site to implement any changes?
Here's the question: How can I update a DLL on a production web site without breaking the app and without re-deploying all of the files?
The thing to remember is that there are web sites and web applications as far as Visual Studio and ASPNET is considered.
Web Sites typically have all of the aspx and vb files published to the live server and ASPNET Worker Process recompiles the app every time before presentation.
On the other end is the web application, where all of your code behind files get compiled down to a single DLL file and you simply deploy your aspx pages and you bin folder with the DLL file to production.
There is also a "hybrid" known as "Precompiled Web Sites" (see the link for the official MSDN overview) where you don't have the single DLL layout of a web application, but all the compile work of the website is done for you. There are several "modes" to this depending on your needs.
It seems to me that your error is caused because your site is set up as a web site with some kind of precompilation in place. Using the pre-compiled model is a little more "strict" in that is assumes certain files/signatures are in place. Having an updated version of the DLL file causes a break since the precompilation wants a name and a version of the file.
If possible, your best bet would be to convert to a web application, since you can add the additional DLLs into production without a problem. Otherwise, take a look at this matrix to see what form of precompilation you need for your application.
Look at this SO post, might be what you are referring to. The located assembly's manifest definition does not match the assembly reference
Have a look at your reference. Does it say "specific version = true" ? Set it to false, republish your app (you have to do it once, because now your app is still looking for an assembly with a specific manifest) and try it again.
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.