-----------------------------------------------------------

New Message on MumbaiUserGroup

-----------------------------------------------------------
From: Swapnil_B1
Message 1 in Discussion

  Folks,   Some of the common considerations which we come across while 
deploying ASP.NET 2.0 Applications is on which method to follow for deployment, 
or how to create the Single dll file like VS .NET 2003 Pattern etc. I will 
address some of the deployment considerations in this article    Regarding the 
previous ages of VS.NET 2003, web project deployment was pretty simple, but 
with limited options. For different types of projects, you may have different 
types of deployment requirements. For example, you may wish only to update the 
dll or contents for each component of the project separately, specially if the 
project is too big to take much time to upload the components  each time. For 
smaller projects, it would be great if we can upload only one file to reflect 
the new changes of a project. In the age of VS.NET 2005, I found that there 
several options have been offered to developers, initially which may make the 
developers confused. Basically there are two basic issues which should be 
considered at the top level of deployment design. One is content based and the 
another one is assembly based. When publishing a web site, there are two 
options are in place in this issue, which are being discussed here 
respectively.    1. Allow this precompiled site to be updatable In ASP.NET 
deployment, we can put the aspx files in corresponding locations, just as a 
place holder, where the contents will be placed in the corresponding .compile 
file in the bin folder, which can be enabled by making this option false. In 
that case, the following issues should be reminded: a. .compile file and the 
corresponding file should be placed for each update of a given aspx, master 
file. If there is only change is code-behind class (i.e. code), this file 
should be included too. 
b. For code change in App_Code, no need to copy App_Code.compiled, just copy 
App_Code.dll ( so far I learned!). 
c. For code change in Global.asax, no need to copy App_global.asax.compiled, 
just copy App_global.asax.dll ( so far I learned!). 
d. For changes in CSS files of App_themes CSS should be copied manually. (I 
don't have tested image and skin files yet!). 
Any way, if this option is true, the deployment still requires .compiled file, 
but not for the pages, but for App_Code folder, App_global.asax files, which 
will be used as a resource locator. So any changes to these contents doesn't 
require to upload this files for the maximum time. I am not sure when the 
updated version of these files should be deployed, but to deploy the updated 
version of these files is a recommended practice!   2. Use fixed naming and 
single page assemblies For deploying assemblies of a ASP.NET 2.0 projects there 
are three ways to do: a. Single page assembly:  In Visual Studio 2005, for a 
ASP.NET 2.0 web application, we can deploy separate assemblies for each pages 
of the site! This can be done by enabling the above option.  If the ' Allow 
this precompiled site to be updatable' is disabled, that means a corresponding 
.compile file should also be deployed with the assembly of each page. In this 
case, if there is any change  in the content (i.e. text etc) of the page, we 
need not to deploy the updated .compile file in the web, as all contents are 
placed in the dll, but as the resource locator or for the basic rule, Atlas one 
version of .compile file should be placed in the bin directory of the 
deployment site. Any way, no matter, whether the change has been done in 
content or code, the page dll MUST be deployed! For a change in content, if 
only .compiled is provided, there is no error, but change will not take effect! 
b. Batch assembly: For different type of contents and codes, different sets of 
assemblies will be generated, if we make the above option false. So any change 
in the code of a page, requires the corresponding set of assemblies to be 
deployed. For aspx pages, there are few assemblies will be generated, with ' 
App_Web' prefix. Since, we don't know, Exactly which ' App_Web..' assembly 
belongs the code for the updated page, we need to deploy all the assemblies 
prefixed ' App_Web' if there is any change of a page. For batch assembly, each 
dll includes a encrypted key in it's name (for instance 
App_Web_pr_login.aspx.16ec59e1.dll), and for separate web publishing, there are 
separate keys for the same type of contents, thus separate file name for the 
newer version. One interesting thing about these assemblies is,  newer version 
of assemblies can reside in the same deployment directory with the previous set 
of versions, without any conflict, and the newer version will automatically 
take place during execution of the corresponding content!  Also, if the 'Allow 
this precompiled site to be updatable' is disabled, and no updated version of 
compile file is provided for the change on content side of the page, only 
deployment of the assemblies will not reflect the change in content side, 
unlike "Single page assembly" deployment. For change in the content side, both 
assembly and .compiled file MUST be deployed. c. Merged assembly:  All of the 
coding contents can be embeded to a single assembly, like VS 2003 age, using a 
VS add-in named 'aspnet_merge.exe' provided by Microsoft. Unfortunately, this 
tool is not provided by default and should be downloaded and installed 
separately.   Swapnil (Swaps) http://swapsnet.spaces.live.com/

-----------------------------------------------------------

To stop getting this e-mail, or change how often it arrives, go to your E-mail 
Settings.
http://groups.msn.com/MumbaiUserGroup/_emailsettings.msnw

Need help? If you've forgotten your password, please go to Passport Member 
Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help

For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact

If you do not want to receive future e-mail from this MSN group, or if you 
received this message by mistake, please click the "Remove" link below. On the 
pre-addressed e-mail message that opens, simply click "Send". Your e-mail 
address will be deleted from this group's mailing list.
mailto:[EMAIL PROTECTED]

Reply via email to