ASP.NET 2.0 Application Deployment in the real world (mine <g>)

ASP.NET 2.0 Application Deployment in the real world (mine )

June 27, 2005 @ 6:43 pm

Since I’ve been back from DevTeach I’ve spent a bit of time converting my West Wind Web Store application to run properly on ASP.NET 2.0 in fact the store on the site is now running on ASP.NET 2.0. I’ll post more about the process in moving in a couple of days.

Part of the reason to do this is that the West Wind Web Store is my main business application that I use here for managing my online and offline sales, and I wanted something real to work with. Taking a chance isn't a problem with this app, because the 1.1 app (and even a Fox app as well) is running side by side with it at the moment, so in case of a problem there's an easy fallback. Moving the app took a bit of work, getting through the conversion errors, some subtle differences and figuring out the best way to deploy the app.

The biggest issue that I’m still struggling with is compilation of the site and how to manage the process of updating a site. I definitely want to pre-compile my site and the only way that seems to make sense is to compile and make the site not updateable.

Anyway, VS.NET doesn’t make deployment easy at all. There’s a Deploy option but currently this dialog doesn’t allow access to all of the features that the compiler has available. For example, it defaults to compiling each and every ASPX/ASCX file into a separate assembly - I prefer the option to build one assembly per directory. The fewer files the better.

VS.NET also includes a Site View dialog that is supposed to allow you to transfer files between your project and a live site, but I don’t see how this can work with a precompiled site as the dialog points at the development directory and can’t be changed. This app looks like it hasn't been update since the Alpha when compilation worked completely differently. This app needs to point at a deployment directory and then allow you to copy files from there. <shrug>

Anyway, at this point I found myself using the command line compiler a lot to build my project(s) to get single assemblies for each directory. Since this is a hassle I built a small utility that helps me with this process so I don't have to remember long compiler syntax lines:

Basically this is a front end the ASP.NET Command Line compiler that can be run without having VS.NET or anything but .NET 2.0 installed. It gives you visual options for the various compiler options (minus the security and signing options which I haven’t looked at yet) plus the ability to choose the runtime version to compile with. You can compile from within the environment and it provides a nice preview of the compiler results which is a bit more readable than what the command line spews out. You can also save a set of settings as a Compiler Configuration so next you need to compile you can just pick from the list of settings.

Finally you can also generate a batch file from the current settings that you can add to your project for automatically building your application as part of the build process (in Release mode maybe).

Given that I can’t do these simple tasks in VS.NET at the moment this has saved a bunch of time and scrambling for my directions on the command line switches for the ASP.NET Compiler. We can only hope Microsoft will add this functionality into VS.NET directly (it looks like the options are in the configuration, but UI doesn’t allow setting them).

I’ve posted this free utility and you can grab it from here:

http://www.west-wind.com/tools/aspnetcompiler.asp

I think I got a little carried away with the UI, experimenting with some of the new UI controls in .NET 2.0 <g>. Too bad that databinding still sucks. Damn how many strikes do they need?

Deployment? Not so fast, buddy

When you use the ASPNET_COMPILER.EXE (or the utility above which drives it), it generates output into a directory – it doesn’t deal with sending files up to a server. The VS.NET UI supports this and allows uploading through FTP, HTTP or a remote file path. I tried that actually, but didn’t have much luck – the FTP upload just locked up VS after sending 10 or so files.

So, I’ve been using the command line compiler, compiling into a directory and then using FileZilla FTP to send the files to the server. The compiler creates output for your entire directory - everything: ASPX files, code files, images, support files, web.config, project and solution files (if any), SQL files etc. Everything.

So, the question is: Would you really want to send your project up lock, stock and barrel? All files to the server? For a first time deployment the answer might be yes. You can send up all of your ASPX files, all your BIN file generated assemblies (all bijillion of them that the compiler generates) and you’re probably good to go.

On my first installation I actually sent everything then went back and deleted a handfull of files that shouldn't be there. Couple of things to watch out for: If you store application settings in your Web.Config you might want to make sure that the setting in there are correct and match your SERVER environment and not your development or staging environment.

Ok, so for first time deployment this full on, copy all approach actually works reasonably well. But what do you do once the app is there and you're updating?

For me and my apps I usually install the app on the server and then tweak code and once in a while, so usually I upload only new binaries to the server. This is in 1.1. Usually there aren’t new pages or files added to the application only the functionality of the existing binaries changes usually. In 2.0 I don't get that luxury.

How about that all or nothing deployment scenario now? I think we can count out the copy everything to the server scenario now. Why should I send all of my images and even the empty ASPX marker files (I compile with the Updateable option off, which generates ASPX files that only have a marker string in them) back up to the server AGAIN? If I do I may get problems with old files that shouldn't be there staying there and I have a maintenance mess.

Really I need to update only the BIN directory. But, it’s not that easy here either. The bin directory now is full of crap – depending on your compiler option you’ll have one assembly per ASPX/ASCX/MASTER etc. file or you have one assembly per directory, plus several others like the APP_CODE directory, your resources and a bunch of other generated code. Everything goes into its own assembly. Plus you have a .Compiler file for each file in the project. Since these files get regenerated everytime you compile, they don’t overwrite the old ones either.

This means for the BIN directory you don’t get a choice of selectively updating files. YOU HAVE TO UPDATE all of them all at once.

Several problems with this: If I copy the files to the server now I end up with two sets of DLLs in my Bin folder which after a few updates gets to be a real mess. I guess after a while I can delete the old files since at least all of the copied files in a compiled project have the same file date. Oh yeah, did I mention: your original file dates in case you needed them are blown away on compilation. That's or the generated assemblies as well as any assemblies that live in the BIN directory of your project for assembly references. Not a big deal for me, but I can see how for some people this will be a problem.

Ok, this is mildly annoying, but there’s a much more serious issue here. The fact that all of these files need to be copied to the server and that these files are no longer in one big assembly that gets updated all at once means that ASP.NET sees the new files coming into the BIN folder one at a time. And it will update the application and shadow copy the assemblies one at a time into the application. Depending on the order in which things get up to the server this can cause some serious mismatches in the application.

In my quick tests copying 50 or so assembly files in my project's bin directory caused my server to spew server exceptions while the update was in progress. Some requests came through Ok, but most failed until the transfer was complete. This makes sense – while copying files, the application is out of sync. This was a problem in 1.1 too but it was minimal because you had basically one assembly for almost all of your codebehind logic. But now you have pages, App_code, Global_asax all depending on separate assemblies which may not get to the server at the same time and while the app is out of sync it is likely going to fail.

Some of the errors were severe enough they even bypassed my error handling that's built into Application_Error. Presumably this can fail to if global.asax or one of its dependencies is 'in transit'.

Conveniently the ASP.NET Admin page has an option to take an application Offline. How thoughtful. Only one problem: The functionality is part of the Web Administration interface, which as far as I can see only runs through the local Web server, not a real Web Server. Meaning it’s of no help on a live server. Regardless I tried it out locally and all that feature apparently does is throw 404 errors when active – hardly the sort of thing you’ll want to show your users.

I ended up putting a maintenance flag of my own into my apps and stick that into my Global.asax.cs file:

protected void Application_BeginRequest(Object sender, EventArgs e)

{

if (App.WebStoreOffline)

{

//if ( !Context.User.Identity.IsAuthenticated )

string Virtual = Request.Path.Substring(0,Request.Path.LastIndexOf("/")+1 );

if (Virtual.ToLower().IndexOf("/admin/") == -1)

MessageDisplay.DisplayMessage("Hold on",

App.WebStoreOfflineMessage + "<p/>" +

@"Usually these operations only take a few seconds, so please retry your request by using

the Refresh button.");

}

…

}

This application specific code gives me a bit more control. I have a static property to control this App.WebStoreOffline, along with a request on my Admin page that toggles this flag on or off. I can get into the admin module by explicitly checking for the /admin/ path of the application – a bit of a heck but a lot more flexible than the default behavior.

I suspect this may still fail because there are still dependencies here: The App class and global.asax.cs class or any of its dependencies might still be out of sync.

So much for real XCOPY deployment. Maybe a little exaggerated, but I really think we lost some features here that weren't worth loosing over this funky compilation scheme that appears to have no upsides for anybody.

Where’s the benefit?

So what’s the upside here? Well, there’s not a whole lot on the plus side. We get an external compiler that we can drive through our projects. And we can precompile the entire site rather than having ASP.NET compile everything as it loads pages. To be honest the latter doesn’t seem to cause any better first page performance than my 1.1 apps. First load of the app is still pretty slow. The overhead is not in the IL generation into assemblies but in the CLR compiling the code into executing binary code and that overhead is still there.

What else? Beats me. It looks to me that this whole Pre-Compilation model has made deployment considerably more complicated requiring manual administration, and it has introduced a serious problem for doing live updates that was rarely an issue before.

Maybe somebody from Microsoft can explain how this model is supposed to make deployment easier or better or more efficient – maybe I’m missing something obvious.

If you find this content useful make a donation

Feedback for this Weblog Entry

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Mårten Törnquist June 27, 2005 @ 11:43 pm

How about the performance once the application is running compared to the Web Connection/FoxPro solution?

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by lynn eriksen June 28, 2005 @ 6:33 am

Rick, this sounds really helpful. I'll have to give it a try.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Bob Archer June 28, 2005 @ 10:50 am

Rick,

My only comment would be, we did you built a utilty to do what I'm sure you can do fairly easily with MSBUILD?

You could also possible have it do your deployment only uplading the new .aspx stubs along with the pre-comiled dlls.

I still think all these changes are for better dev experience rather than deployment experience.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl June 28, 2005 @ 11:09 am

Bob,

I didn't create a build utility, I built a graphical front end to a comand line utility. And yeah, I can create a batch file too. <g>

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl June 28, 2005 @ 11:12 am

Marten,

The ASP.NET Store app scales about 2 x better than the equivalent VFP solution. Perceived performance is roughly the same until the 80% load point is reached.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Thomas Eyde June 28, 2005 @ 10:10 pm

Bob, I can only say that the Developer Experience (tm) sucks. Big time.

I have had the unluxury to use several ctps and, finally, the real Beta 2. Beta2 *is* a more stable product, but there is so much more to desire that I still desire 1.1. In weak moments I even want to make the jump to Java.

The new things in ASP.NET compiling/deployment puzzles me to the extent that I wonder what they (those at Microsoft) were drinking. Or smoking.

My general feeling about 2.0 is that I want to avoid it, almost at any cost. I take it that was *not* Microsoft's intention, so some Product Manager(s) over there have made some big mistakes.

What happened to KISS?

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl June 28, 2005 @ 11:05 pm

Thomas,

Ouch <g>. Well I think that ASP.NET 2.0 is a big improvement over 1.1. I agree with the statement that the new compilation model changes are not an improvement but a huge step back. They make the simple stuff easy but as soon as you do anything non-standard in regards to page referencing or inheritance, you either can't do it or you have to REALLY understand how the freaking complex model works.

I like many other don't see why the page model couldn't have been fixed with working out the issues with teh 1.1 model which was fine except for the control generation/event hookup into the base class. That really was the only major problem. That coulda been fixed just by extending base class to be a partial class and leaving the rest of the compiler model alone.

It'll be interesting to see how novices will struggle with these issues...

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Michael Carr November 08, 2005 @ 1:56 pm

With VS2003, I frequently used the "build" process (ctrl-shift-b) as a first-line check against obvious code errors, using the error box to track down stupid mistakes. The build process went through the source files and converted them to IL, which was then saved in a DLL file. This process took only a couple of seconds even for large projects.

With VS2005, the "build" process, at least for websites, compiles to IL as before but ALSO does an in-place precompilation to machine code, such that when you start the website there is no delay in loading the first page. Unfortunately, this conversion to machine code takes a while for large projects (40 seconds or more) and is unnecessary for 99% of my builds where I am only interested in checking for obvious coding errors. As far as I can tell, there is no way to configure VS (or the command tools, for that matter) to use the 2003-style IDE build step, where the compiler generates IL only... does anybody know of a way to keep it from going all the way to generating machine code? This new "functionality" is slowing my development cycles to a grinding halt!

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rory Richter January 23, 2006 @ 5:23 am

The only reason I can think that they made the default deployment method create an assembly for each aspx/ascx is to allow to live production site code behind updates without the IIS restart and/or session state loss. This model does allow for this does it not???

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl February 11, 2006 @ 10:03 pm

Rory,
Yes it does, but who will *deploy* both ASPX and source files on the server?

Many of the issues I've mentioned in this article are addressed by:

Web Deployment Projects
http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

and
Web Application Projects
http://msdn.microsoft.com/asp.net/reference/infrastructure/wap/default.aspx

The former provides single assembly compilation, while the latter allows VS2003 style projects to be created with VS.NET 2005.

It's a shame that both of those features weren't part of the base install, but at least we're getting this functionality as an addon.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Sahin February 13, 2006 @ 10:29 am

Dear Rick,

You are the God of Asp.net Articles.

It is possible to add a feature to your WebDeploymentSetup tool, so that It only deploy
changes (dlls,aspx).

Thanks.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl February 13, 2006 @ 11:02 am

Sahin, Unfortunately not. The problem is that ASP.NET needs to compile the project first and in the process changes all the timestamps. If you compile at all you will need to redeploy everything.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Ben Mills February 20, 2006 @ 6:51 am

I'm really struggling with these compilation/deployment issues. It took me less than a day to convert a large ASP.NET 1.1 application. Everything works great and I was ready to make the switch on my production server, then I hit the compilation/deployment nightmare. I've been working on this for 2 days and I'm very frustrated.

I had a great deployment solution for ASP.NET 1.1 where I had a sync process that updated the .aspx and .dll files that had changed when building the project (based on changes to the timestamp). There were 2 problems with this solution:

1. Any requests on the production server could fail for the 15 seconds that I'm uploading the new files (not a big deal).

2. All the sessions were wiped out. So if a customer is midway through a checkout, then they get an error (this is a big deal).

Problem 1 seems to be worse in ASP.NET 2.0, because all the aspx file timestamps change, so my sync tool wants to copy all the files, which takes close to 5 minutes.

Can anyone tell me if sessions are wiped out when copying the dll's in ASP.NET 2.0?

As you said Rick, I don't really understand what the ASP.NET team were trying to do.

I tried the web deployment project, but it still modifies the timestamp on all the aspx files. Asll it really does is combine multiple dll's (though it does have a nice feature to modify parts of the web.config file for staging/production environments).

I guess my main beef with all this is that it's really hard to make small updates a large project and deploy just the changes as fast as possible without wiping out session state.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl February 20, 2006 @ 10:53 am

Hi Ben,

#2 was always a problem even in 1.1 - when you replace existing DLLs, the ASP .NET AppDomain needs to be unloaded and reloaded which causes Sessions to be lost. Actually ASP.NET doesn't need to unload in all situations - only if existing DLL change.

The difference is that in 1.1 not everything was compiled in the BIN directory so you could swap the ASPX files without a hard update. This still works in 2.0 too but you need both code and ASPX in the Web dir for this to work.

But the problem with #1 is that many files are updated so ASP.NET sess the folder change frequently so it actually may end up restarting more than once in the course of an upload in a state of version mismatch.

I think your solution is ASP.NET Web Application Projects which works like VS2003 and does single assmebly compile of all your codebehind. But # 2 is a problem there as well. To address look into using the StateService for Session data.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Tom McKeown March 01, 2006 @ 6:04 am

Rick,

what if you deploy 100% source? I'm not suggesting this as a great idea I am just curious. Would you have to deploy all source code everytime too? I think this deployment strategy is very.... ummm how do I say this.... dumb!

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl March 01, 2006 @ 9:39 am

If you do full source deployment you can XCopy deploy and only update what's changed. No need to run the ASPNET_COMPILER in any way. It is the easiest way to deploy for sure, but it does mean the source has to go onto the server.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Monsur March 10, 2006 @ 11:22 am

Hi there. I'm a little annoyed by all the oddly named dlls ASP.NET 2.0 generates, so your tool looks promising. However, when I fire it up, the "Merging" option is completely disabled. Is there some dependancy for merging to work? Thanks!

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl March 10, 2006 @ 11:25 am

You need to download and install the Web Deployment Projects from the Microsoft site:

http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

The tool uses the Microsoft command line tool to provide the merge functionality.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Frank March 20, 2006 @ 3:28 am

Rick,

I'm about to upgrade a site with webshop to 2.0 and like Ben, the #2 problem with session reset is a major issue that I want to solve. If I understand the discussion correctly I have two options:

1. Use "Copy web site" (=Xcopy) and publish source code to production server. First time hits will suffer a delay, but can use default session state.

2. Precompile with your tool and use StateService. Avoids source code on production web server.

Other issues I should pay attention to? Thanks!

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Mark March 24, 2006 @ 11:15 am

Hi Rick

I got a bit of an insight into the MS thinking in the following MS article http://msdn.microsoft.com/asp.net/reference/infrastructure/default.aspx?pull=/library/en-us/dnvs05/html/internals.asp#internals_topic3

It covers the new approaches to compilation. It even shows the use of the \app_code directoty approach, which allows you to *just* copy and paste aspx and cs files without any precompling.

Combining that with the SessionState server implies you can update you site without losing session or your website while you are updating the files.

The downside of the app_code is that you have to store source code on the web server but this is something we have had to live with before in classic asp.

Before I go down this route has anyone tried this approach and are there any major pitfalls?

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rory Richter March 31, 2006 @ 1:04 pm

Rick,
Yes. I fully agree with your reply to my first post. That's why I was slightly ironic in the post because at first I was also completely perplexed as to why they didn't offer the vs2003 build style as another build option inherently. I cannot think of a reason to want a ASP_NET_[Hash] assembly for every aspx page. Maybe they saw everyone doing live development on their server and noticed all the back end code files were deployed anyway, so they said "ok, since you want to deploy code behind files.." :) (I have seen that many times in many different shops. hehe)

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Brian April 28, 2006 @ 9:21 am

Rick,
Excellent work here, thanks for the research. I have been struggling for 2 days when I ran across your post. Imagine this: The VS2005 Team at Microsoft work in a civilized environment, and one week before release someone says "Shoot! What about deployment?". Another replies "Got it covered. Looks over to a door with a padlock on it, and a sign that says 'asp.net package and deployment'"... and shots "Hey Igor, are you busy?". :-)

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by hongson June 01, 2006 @ 8:44 am

hello rick,
yeah, first of all, like others i wish to thank you for presenting a very informative info. like others, i have been trying to get my head around this new world of ASP.NET 2.0 and its many possibilities.

it's pretty clear that microsoft rushed out vs2005! yes, they provided the deployment project add-in but that's just the point, it should have been built-in. they often seem to forget that all of us developers actually work with the current version of a product; they expect us to just drop everything and jump on the latest-is-the-greatest wagon.

anyway, enough of whining and onto my question. i have by now figured out how to use the Web Deployment Project and have successfully launched a site. but i've learned a couple of things in doing so:

1) single assembly name cannot be the same as the project namespace; otherwise, i was getting aspnet_merge complaining about assembly containing external references to itself.
do you know why?

2) so, i see the single assembly output which i upload to the target server. of course, i also upload the .compiled files to the ./bin folder and the marker files to the app folder. but there is another project assembly file which i did not expect to see or have to upload. using Reflector, i see that this assembly has the actual page UI controls. why isn't this assembly folded into the "single" assembly?

thanks for any insight... i'm getting there but still not quite there.
hong

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by Rick Strahl June 01, 2006 @ 1:41 pm

I don't know about #1, but I'm building my WDP assembly with the same name as the main namespace and I have no issues. I suspect you may have some other naming issues that may look for an assembly by that name explicitly somewhere or you have a reference set to this?

I also don't see #2. What do you mean by UI controls? WDP only compiles the Web project itself, not any support assemblies. So if you have external assembly references those assemblies (say custom Server Controls or a Business Object Library) still will be external.

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by hongson June 02, 2006 @ 1:04 pm

yes, i don't understand it but here's the error message:

An error occurred when merging assemblies: ILMerge.Merge: The target assembly 'cwSharp2' lists itself as an external reference.
C:\Program Files\MSBuild\Microsoft\WebDeployment\v8.0\Microsoft.WebDeployment.targets(574,9): error MSB6006: "aspnet_merge.exe" exited with code 1.

if i simply change the single-assembly name to "codesworth",
merge succeeds but as i stated in #2, in the output /bin directory, there are 2 assemblies: cwSharp2.dll and codesworth.dll.

cwSharp2.dll contains UI.Page-derived aspx pages (i have 3 such pages); while codesworth.dll contains those ASP-drived classes but it also
includes one page from cwSharp2 namespace (why i don't know and perhaps, this is the real issue?).

i also should mention that cwSharp2 has two web references, one on localhost and the other on remote server (the real thing). of course, localhost reference is for local testing and Debug only. is there a way to conditionally include/exclude web reference in the assembly?

# re: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by KFRA July 02, 2006 @ 7:43 am

"Only one problem: The functionality is part of the Web Administration interface, which as far as I can see only runs through the local Web server, not a real Web Server. Meaning it’s of no help on a live server. Regardless I tried it out locally and all that feature apparently does is throw 404 errors when active – hardly the sort of thing you’ll want to show your users."

Hi,
if you use the App_offline.htm feature, you should make sure you have at least 512 bytes of content within it to make sure that your HTML (instead of IE's friendly status message) shows up to your users.

Regards,

Francesco

# ASP.NET Forums - Problem with 'Publish WebSite'
by Visual Studio 2005 October 11, 2006 @ 9:25 am

# ASP.NET 2.0 Project Deployment Tool is here - Rick Strahl's Web Log
by Rick Strahl's Web Log October 15, 2006 @ 6:35 am

Microsoft has finally released the Web Deploment Projects Add-in that promises to bring back some of the missing flexibility of ASP.NET 2.0 Web projects...

# The joy of working with 2 versions of .NET - Rick Strahl's Web Log
by Rick Strahl's Web Log October 24, 2006 @ 4:02 am

I've been working on my Web Store software mostly for internal stuff for a while in .NET 2.0. Recently it turned out that I needed to do some paying work with the 1.1 version and in the process I've found myself going back and forth between the two and backfitting changes from one to the other. Not a fun excercise.

# VS.NET 2005 Web Project Manager Tool - Rick Strahl's Web Log
by Rick Strahl's Web Log October 24, 2006 @ 12:01 pm

Microsoft has heard some of the complaints about the ASP.NET 2.0 project deployment issues and they are planning to release an Add-In project type that provides the missing features to control deployment much better.

# DotNetSlackers: ASP.NET 2.0 Application Deployment in the real world (mine <g>)
by DotNetSlackers Latest ASP.NET News November 09, 2006 @ 6:46 am

# re: ASP.NET 2.0 Application Deployment in the real world (mine )
by mogi November 14, 2006 @ 9:17 pm

hi guys, i'm faceing strange problem, i have an asp.net 2 we site when i deploy it on the production server, if i deploy it as virtual directory it works well if i make it new web site, it ask for windows user name and password

# re: ASP.NET 2.0 Application Deployment in the real world (mine )
by fargii May 04, 2007 @ 2:20 am

Hi Rick,

I downloaded the West Wind ASP.NET Compiler GUI Tool and pluged it into VS 2005 as an external tool. It is awesome!. I use it to build single assembly releases for .NET 2.0 projects
web projects. Thanks for releasing such a great tool.

fargii

# ASP.NET Forums - Publishing my web site and administrating it.
by Configuration and Deployment May 07, 2007 @ 8:19 am

# Publishing my web site and administrating it. - ASP.NET Forums
by ASP.NET Forums July 11, 2007 @ 10:41 pm

# K. Scott Allen : When Deployment Gets Ugly
by K. Scott Allen July 15, 2007 @ 8:00 pm

# Problem with 'Publish WebSite' - ASP.NET Forums
by ASP.NET Forums July 21, 2007 @ 5:50 am

re: ASP.NET 2.0 Application Deployment in the real world (mine )
by micvoiss January 25, 2008 @ 11:58 am

You do an excellent job of explaining things to the novice, and I for one truly appreciate that. Great articles and thanx for the asp.net compiler ui. It's a great tool.

# re: ASP.NET 2.0 Application Deployment in the real world (mine )
by JohnC February 22, 2008 @ 2:32 pm

In reference to that problem mentioned by hongson June 02, 2006 @ 1:04 pm

"An error occurred when merging assemblies: ILMerge.Merge: The target assembly 'cwSharp2' lists itself as an external reference. "

I too got that same error and it drove me crazy for a while (or maybe it was the flu :) ) but it turned out to be a lack of understanding. My previous experience with WDP was using it with a standard web project and that went fine because it doesn't normally build into a .dll file and there is no output assembly so no possibility for conflict.

However with a web application project it *does* of course output a .dll and here is where I went wrong: I thought that the web deployment project would compile all my pages *and the output .dll* into one assembly so I gave both the web application project and the web deployment project the same target assembly name which you can not do.

What WDP does with a WAP is put the *page content only* into the consolidated .dll but you still require the separate .dll that was built from your code behind the pages as well as other areas of your web application project.

So to summarize when you use a web deployment project with a standard web project you end up with a single .dll. When you use WDP with a web application project you end up with *two* separate .dll's which of course can not have the same name.

Hope this helps someone in future. What I did is set the WDP to output the same named assembly as my web application but with .pages.dll instead just so it was clear in my head in future.

re: ASP.NET 2.0 Application Deployment in the real world (mine )
by Larry Herbinaux November 12, 2008 @ 2:05 pm

Rick,

I am using the updatable option, copied the entire results to the production server, stopped IIS, renamed the top-level application directory (e.g. current to old, etc.), and restarted IIS.

I'm confused because the first time access each page the vbc.exe is being kicked off and compiling the page into framework's temporary area. I understand that items in the bin directory are shadow copied, but why is the compiler being kicked off as if an In-place compilation is being performed. Is the framework's temporary area considered the shadow cache area also? Here's an example directory

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\amsproto\5b1f6180\82a8219e\assembly\dl3\0a8e2635\001ac329_f844c901

one directory under the dl3 directory for each page. Prior to deploying a precompiled version, I thought the results of the in-place compile were being stored farther up the tree in the

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\amsproto\5b1f6180\82a8219e\

I would think that the shadow copy service would just look into the bin directory and make a shadow copy when I started IIS back up instead of compile on each page hit...this seems bizare to me.

Thanks in advance.

# re: ASP.NET 2.0 Application Deployment in the real world (mine )
by Martini January 20, 2009 @ 2:18 pm

Thank-you, JohnC! I had exactly this issue today with a web site that I had to convert to a web application with a deployment project. The strange thing is that I have other web applications with WDPs and they *do* work with the same name (and a single .dll output). Perhaps the settings in their web application project are slightly different and I haven't noticed. But, I digress...

Your excellent research has saved me countless frustrating hours. Thank-you again, for posting your findings!

It would be nice if the deployment project (or perhaps the merge tool) would pick up on this and at least provide a more helpful error description. *hint* Microsoft?