Is it possbile to develop using the 1.x compiler model with a codebehind that is compiled into the DLL in the /bin directory? I have not seen that option in any of the dialogs for ASP.NET development.

Thanks,,
Charlie

Hi Charlie,

Thats the model im using in .NET 2. When you create a new page make sure the "place code in a seperate file" box is ticked. You can find that option on the right hand side of the language drop down box which in turn is below the name box.

Hope that helps
Andy

Well, I am seeing slightly different results. I have the "Place code in a seperate file" checked, and I am seeing a codebehind file. However, it is not compiled into the bin directory. Instead, it is compiled on the fly, in the new 2.0 compile model.

Any ideas how to tell VS.NET to compile it and put it in the bin directory?

- C

In the new compilation model the code-behind compiles at the same time the runtime parses the ASPX file and compiles it. The resulting assembly will end up in a sub directory of the Temporary ASP.NET Files folder where the framework is installed (unless you use the precompilation tool, see http://odetocode.com/Articles/417.aspx).

Sorry Charlie I misunderstood the question.

As bitmask points out in the default code-behind model code files are compiled at runtime and DLLs are created in a temp directory of the framework.  This of course means you need to deploy all code files with the application if you use this model.

Two other models are available in 2.0 but neither will provide what you are looking for.  They are available via Build / Publish Web Site.

One method will precompile your entire site into DLLs and aspx stubs that contain no code nor markup.  Using this method you must compile and deploy the entire site - which means it must be deleted, yes, deleted first.  If you have a site with hundreds of files and you need to make a change to only one of them - from what I understand you need to delete your entire web site and re-deploy everything.

The other method will allow the site to be 'updatable'.  This method will create aspx files that contain markup as well as a number of DLLS.

Each of these methods compiles all of the necessary files to a sepearte directory and though the updatable method still maintains your markup in the aspx files, THEY ARE DIFFERENT.  Your original aspx files can not be deployed; the modified version created during the 'Publish' must be deployed because slight changes are made to the Page directive to properly link the page to the compiled DLL.

There is currently NO WAY to hit compile, and have all pages compiled to one or more DLLs into your bin directory leaving your aspx files untouched.

IMHO this is an absolutely deplorable decision and I only hope this will be changed before release - but it appears unlikely.  I can't begin to explain how frustrating the currently available deployment models are but here are a few links regarding this very issue (please vote on them):

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackId=d35e0b41-d07f-429d-9137-15d0eaaee58e

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackId=09af3c3f-adc7-436d-ae8d-d7bcf174e0c7

I draw these conclusions from working with the July CTP of Visual Studio 2005.  If this is no longer the case in the August release, or I have completely overlooked the ability to compile directly to the \bin please let us all know.  I would very much like to be wrong.

Mike

mhardy wrote:

One method will precompile your entire site into DLLs and aspx stubs that contain no code nor markup.  Using this method you must compile and deploy the entire site - which means it must be deleted, yes, deleted first.  If you have a site with hundreds of files and you need to make a change to only one of them - from what I understand you need to delete your entire web site and re-deploy everything.

The -fixednames switch on the precompiler will produce dependable assembly names. It is possible to patch just the code for one web form this way.

mhardy wrote:

Each of these methods compiles all of the necessary files to a sepearte directory and though the updatable method still maintains your markup in the aspx files, THEY ARE DIFFERENT.  Your original aspx files can not be deployed; the modified version created during the 'Publish' must be deployed because slight changes are made to the Page directive to properly link the page to the compiled DLL.

If you precompile without the updateble option, you can deploy just the .dll files. The big catch is IIS won't hand control over the the .NET runtime when looking for a default page, so there is no automatic redirect from / to /default.aspx unless there is a default.aspx file in the directory (even an empty default.aspx). Even still, I'm not sure why deploying from a different directory of ASPX files would be such a pain. All you need is a staging area, which the publish option or the aspnet_compiler can setup for you.

There will also be a utility out at the same time that VS 2005 releases that will allow you to take the output of a published web and merge all generated assemblies into a single assembly that you name.  This will give you the same deployment characteristics that VS 2003 had in compiling all code-behind everything into a single assembly.  You will be able to use this utility either standalone, or integrate it directly into your build process.

Hope this helps,

Scott

bitmask wrote:

The -fixednames switch on the precompiler will produce dependable assembly names. It is possible to patch just the code for one web form this way.

Fantastic!  However, here's the rub, since they are all recreated during Publish they are all dated the same making change set deployment a painstaking, time consuming exercise.

bitmask wrote:

Even still, I'm not sure why deploying from a different directory of ASPX files would be such a pain. All you need is a staging area, which the publish option or the aspnet_compiler can setup for you.

Very simply because it creates more work.

Let me explain...

I maintain around 30 sites each with between 10-200 pages.  I frequently make changes to individual pages, or multiple pages within a single application of a site.  Once these changes are made and tested locally (by simply hitting run), I want them deployed - just the pages that changed (and any relevant dlls).  Especially if they're bug fixes, I want them deployed as fast as possible - but absolutely only those pages.  Deploying the entire web site is not an option, for countless reasons.

In essence, I want to deploy directly from the IDE, but only those files that have changed.  i.e. make change(s), hit run, test changes, deploy changes.

With the current model that is just not possible.

If I 'Publish' to a staging area I then need to browse to the staging area, try to find the file(s) that changed (which all have the same date now), connect to my server and copy the files up manually.  That is a considerable amount of overhead when done frequently throughout the day.  I of course can't set the Publish options to publish to the live server because that would delete my entire site, I can't believe that's really an option for anyone.

Unfortunately most of the small to medium size businesses I work with do not have a QA department nor a stringent deployment schedule.  Though that would be nice, it is simply not the case for numerous companies.  They want changes, they want them now, and they want minimal downtime (i.e. no deleting the entire site! :)

So the ability to merge DLLs, though a nice option, is not really of great concern for me.  I actually prefer the new method of having multiple DLLs so change is more contained.

I guess it all boils down to the fact that my overall concern is that I still can not easily publish incremental changes.  For so many websites that is absolutely key.  The fact that I hit 'Publish' and receive a dialog that says "Existing files in the destination location will be deleted.  Continue?"  is almost laughable to me.

But then again, maybe I'm just in the minority... ;)

Thanks for the response Scott, I do much appreciate your insight.  I'm just frustrated that what seems an obvious workflow is still not handled very well.

I simply want, compile, test, deploy changes.

Mike

Hi Mike,

When you publish you'll get all of the files copied to that directory, but the origional time-stamps on the source files are never changed.  This means you can do one of two things:

1) Refer to the timestamps of your source .aspx/.ascx files when figuring out what to copy

2) Write a utility that actually takes the time-stamps of your source files and updates the timestamps of your published files to match them.  That will allow you to then use your standard file-copy workflow and compare your file-stamps on the server with what you have in the published directory.

Hope this helps,

Scott

BTW -- I'll try and put together a MSBuild utility that you can use to-do this.  I'm heading off to PDC and then a long vacation right afterwards, so there is a chance I might not get to-it until I return, -- but I should be able to get you something that does this that is easy to add to your projects.

Thanks,

Scott

Scott-

That would be absolutely fantastic.  Enjoy your vacation, and thanks for anything you might provide on your return.

Mike

As I was reading through this thread, I was getting pretty excited because this is exactly the issue I'm encountering.

I work exactly like mhardy describes.  Here is my real life issue that caused me to search the forums.

I dragged a comparevalidator onto a form that didn't need one as an experiment, and published the site that way.  Now I need to remove that comparevalidator and reupload that page, here is what I've encountered.

Uploaded the filename.aspx, no go here (I knew it wouldn't), it asks for the .vb.  I'd prefer not to upload the .vb, as I don't want to give sourcecode to customers without charging them for it.

I can't use the publish tool because it would delete the images would take a long time (meaning the site would be down for the duration), and the web.config is different on the live server (different smtp server, different connectionstrings, and I use a setting called istest which tells the site whether to use .local or .com for dynamically generated urls).
So I assume I need to upload the assemblies. 
I see the msbuild options, and I know how to use the msbuild command prompt, but I'm trying really hard not to use it in this instance, as I have over 30 websites and I am trying to figure out how to use VS2005 to do what I want so when I need to do a quick change like this I can do so with minimal fuss.

At this point, with the full version of VS2005, can someone tell me what my most efficient means is for quickly editing one page out of dozens of websites and upload the appropriate assembly?  Preferably without scrounging through my temp folders and trying to guess which assembly equates to the file's folder I just changed.

Here is my dream of how it would work (it would be even better than 1.1's ease of updating!)
A) Customer calls me and /members/featuredproperties.aspx has a typo.
B)  I change the typo, click Build from the Build menu in VS2005.
C) I click copy website, open the ftp, browse to the precompiled_code folder.
D) I find App_Web_member_72uulx1k.dll and upload it.
Done.

Is that, or something like it possible at all?  If so, I would appreciate someone who could steer me in the right direction.  Working in asp.net 2.0 started as a dream, but the nightmare of constant constant updates for projects in progress is beginning to really increase my stress level.

 

Hi Richard,

Here is the web deployment project utility I mentioned earlier in the thread: http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx

Here is information on how to download it and ask questions: http://weblogs.asp.net/scottgu/archive/2005/11/10/430283.aspx

This will allow you to build your website and have more control over assembly versioning (for example: MyCompany.MyWebApp).  For example, you could have a single assembly with a fixed name if you want -- in which case you would just copy the .aspx file and the 1 .dll assembly for the scenario you listed above (just like VS 2003).  You could also alternatively have a separate assembly per folder if you wanted to make more granular updates.

Hope this helps,

Scott

I just wanted to say thanks!  This has so far worked tremendously, and even one upped my previous 1.1 interface because now I'm not so afraid I might "accidentally" upload the web.config when I upload everything else. 

I will say that I, like many I think, work off of a development server and encountered the problem described in KB 843584, I followed the steps, and now I'm up and running.  Fantastic tool Scott!