C# .NET - how to create setup file of website.

Asked By sushant kumar kesari

29-Sep-11 01:11 AM

hello frnd

i want to setup file of my website.

how to create that on.

plz reply asap.

Suchit shah replied to sushant kumar kesari

29-Sep-11 01:14 AM

Creating a Web Setup Project using Visual Studio

Follow below guidelines to create msi installer for deploying ASP.NET web sites with VS2005,

1. Open the web application (by selecting the sln file).
2. Select File (in the menu bar) >> Add >> New Project
3. ‘Add New Project’ Dialog box appears
1. Select Project type as Other Project Types >> SetUp and Deployment.
2. Select the Template as Web Setup Project.
3. Note : – Select the Location, where we want, the msi file to be created and Change the Name, as the folder name, we want, in wwwroot, to be created, when msi file is installed.
4. File System of the created project will be opened. Under File System on Target Machine >> Expand the Web Application Folder >> (Bin will be available) >> Right click on bin folder and add the files/assemblies that should be available in the Bin Directory when the msi file is installed.
5. Right click on Web Application Folder >> Select Add >> Project Out Put >> Add Project Output Group Dialog box will appear >> Select the Primary OutPut in that Dialog box >> And click ok.
6. Again Right click on Web Application Folder >> Select Add >> Project Out Put >> And in Add Project Output Group >> Select the Content Files >> Click Ok.
7. Optional : – If you want to provide the Source Files also (cs/vb files also to client). Then – Right click on Web Application Folder >> Select Add >> Project Out Put >> And in Add Project Output Group >> Select the Source Files >> Click Ok.
8. Add the required files to the appropriate folders. (For example in Worms Project we want Reports Folder which contains the rdlc files and its corresponding datasets, which are essential for the reports to get generated. So we created Reports (WebFolder) and added all the necessary files into that folder.
9. If you are using Master page concept then we have to add the MastersForm.aspx and aspx.cs file also. To the Web application Folder.
10. Right click on the webSetUp Project>> Select View >> Custom Actions
11. Custom Actions Dialog box appears >> Here Exists the Custom Actions for the added project. The Actions are Install, Commit, Rollback, Uninstall.
12. Right click on Install >> Select Add Custom Actions >> Select Item in Project Dialog box appears >> Double click on Web Application Folder >> Select Primary OutPut from ProjectName (Active).
13. When creating web projects in 2005, the default installation of a web site/web service would create the virtual directory with ASP .NET version set to 1.1. To change the version to 2.0 we have a script changeaspnetversion.vbs in vault. Add this script to the main web project and also add it to web setup project by Right click -> Add -> File. (the file ChangeAspNetVersion.vbs should be added).
14. Select Primary out put from Web SetUp Project >> Press F4 >> In the Properties of Primary Output (File Installation Properties). We find the ExcludeFilter >> When we select on the Browser button by its side >> Filter Dialog box appears >> Select Add Filter >> Add Filter Dialog box appears >> type the name ChangeAspNetVersion.vbs and press OK, similarly type web.config and press ok again by entereing into this dialog. >> Now press Ok for Filter Dialog box.
15. Under “Web Application Folder”, select web.config and view properties (F4). Change the “Permanent” property to true. Set the “Condition” property to “NEWINSTALL1”.
16. Right click on web setup project, select “View >> Registry”. Create the following key under HKEY_LOCAL_MACHINE >> SOFTWARE >> SEDC >> {name of the project}. For the last key add a “String value” called “Installed” and set its value to 1.
17. Right click on web setup project, select “View >> Custom Actions”. Add a custom action to install by selecting “changeaspnetversion.vbs” from the “Web Application Folder”. Go the properties window (F4) of the custom action created above. Set the value of property “CustomActionData” to “[TARGETVDIR],[TARGETDIR]”.
18. Right click on web setup project, select “View >> Launch Conditions”. Right click on “Search Target Machine” and select “Add Registry Search” Rename the Registry Search as ProjectName. Go to the properties window (F4) of the registry search created above. Set the properties “Property” to “NEWINSTALL”, “RegKey” to “SOFTWARE\SEDC\{name of the project}”, “Root” to “vsdrrHKLM” and “Value” to “Installed”.
19. Go to the properties window (F4) for web setup project. Set the properties “Author”, “Manufacturer”, “Post-build event”, “Product Name” accordingly and set “Remove Previous Version” to true and The version number for the web setup project has to be changed whenever an updated application has to be deployed.
20. Build the web setup project and find the msi file in the Release/Debug folder where you have specified.

smr replied to sushant kumar kesari

29-Sep-11 01:15 AM

hi

Well here are some links to help you to deploy it;

http://msdn.microsoft.com/en-us/library/ms228283(v=vs.80).aspx[http://msdn.microsoft.com/en-us/library/ms228283(v=vs.80).aspx]

http://www.codeproject.com/KB/database/Deploy_your_database.aspx[http://www.codeproject.com/KB/database/Deploy_your_database.aspx]
Or you can add you own custom code in other "steps" (called custom actions)
inside the setup. In those steps, you will be able to execute the database
initialization, using for instance a db restore command. For this look at this web page;

http://msdn.microsoft.com/en-us/library/49b92ztk(VS.80).aspx[http://msdn.microsoft.com/en-us/library/49b92ztk(VS.80).aspx]

Also when you add an installer on its properties if you indicate the Target Platform to "x86" that will do it I think.

Suchit shah replied to sushant kumar kesari

29-Sep-11 01:17 AM

The web project model changed in a number of ways between VS 2003 and VS 2005. There was a lot of discussion this August over missing features that weren’t supported or were broken by it in Beta2 (examples: exclude file from project support, file-based assembly refreshes, the ability to not check-in \bin assemblies in source control, etc). These specific issues were fixed in the final release of VS 2005, and a number of folks who previously had a lot of concerns have posted positive impressions of the new model lately.

One of the things we on the team still weren’t happy with, though, was the level of support in the vanilla product for more advanced deployment configurations/options beyond the core "Publish Web" scenarios built-into VS 2005 – specifically around assembly naming/output, advanced MSBuild customization, and other common scenarios that we’ve heard requests for over the years (for example: the ability to modify connection string settings depending on the build configuration, etc).

A couple of guys on my team have cranked over the last 2 months adding richer support for these scenarios that integrate nicely in the shipping product. We’ve packaged up this work in a new free download we call “VS 2005 Web Deployment Projects” and which we worked to make sure was available for download this week (which is the week of VS 2005 launch -- so basically immediately when the product releases). This download does not touch any shipping binaries within VS 2005, but instead uses the extensibility support within the IDE and ASP.NET to integrate in a fairly cool way.

We think the resulting feature-set offers the best of both worlds – specifically the http://weblogs.asp.net/scottgu/archive/2005/08/21/423201.aspx, as well as the richness of a highly customized build/deployment system.

VS 2005 Web Deployment Project Feature-Set

The VS 2005 Web Deployment Project download adds a number of features that integrate nicely inside VS 2005 including:

1) More control over the number of assemblies generated by a pre-compiled web project, as well as control over their naming. Specifically, you can now generate a single named assembly for all pages + classes in your web project (for example: MyCompany.MyWebApp.dll). Alternatively, you can also now optionally generate a separate named assembly for each directory of pages/controls in your project (for example: MyCompany.MyWebApp.SubFolder1.dll and MyCompany.MyWebApp.SubFolder2.dll). This later option is particularly useful for large content web-apps where you would like the ability to incrementally patch code updates.

2) The ability to utilize the full power of MSBuild to customize your build process. You can now use MSBuild to define pre and post build rules, exclude folders from building, automatically create IIS vdirs and site mappings, add custom assembly versioning information, and add any custom MSBuild task you want to your build process.

A VS 2005 Web Deployment Project stores all of its settings inside an MSBuild based project-file. It also adds support for opening and editing the web deployment MSbuild project file directly in the IDE (w/ full intellisense support for it) – something that actually isn’t supported by any other project type in VS.

3) The ability to define and use custom build-configurations inside Visual Studio, and define per-build configuration options. In addition to using the built-in “debug” and “release” configurations, for example, you could define custom build configurations like “staging”. You can then vary your web deployment MSBuild tasks and actions based on these.

4) The ability to customize and modify a web application’s web.config file at deployment. There is now IDE support for changing values likes connectionstrings or app-settings as part of the build process. You can also vary these values based on the VS build configuration – so for example you could have one set of connectionstrings that you use for development (when you have the build configuration set to “debug”), and then have them modified as part of the build-process to your test/staging or production databases when you choose a “staging” or “release” build configuration in the IDE.

There are also a host of other features to take advantage of. The upcoming whitepapers on MSDN will go into more detail on these, as well as the 40+ new web deployment related MSBuild tasks that it ships with that you can use to customize things even further.

Example Walkthrough of using a VS 2005 Web Deployment Project

Below is a simple example that walks-through using the VS 2005 Web Deployment Project download to customize the deployment of a VS 2005 based web site project.

Step 1: Development my web project

Below is a screen-shot of a common web application solution structure – where I have 1 or more class library projects and then a web-project containing my web app.

I can build the application using the standard web project model that ships with VS 2005, and take advantage of the productivity enhancements it provides.

Step 2: Adding a VS 2005 Web Deployment Project

As my web app progresses, I’ll need to think more about deployment. To take advantage of the new deployment features the web deployment add-in provides, I can right-click on any of my web projects in the solution and add a Web Deployment Project (note: it is the 3^rd item in the context menu below):

This will prompt me for what I want to name the project and where to store its project file:

The web deployment project will then show up as part of my solution:

Associated in the e:\WebSiteDeployment directory is a new MSbuild based project file that contains deployment and build settings for my web-project.

Note that a single web-site project can optionally have multiple deployment projects associated with it. You can also have multiple web-site projects in a solution, each with a separate web deployment project (for example: a user control library project that you pre-compiled and then copied into another web app project that used it).

Step 3: Setting Build and Deployment Options

To customize build and deployment settings I can either use the built-in GUI property pages for the deployment project, or edit the MSBuild file directly. I’ll show this second more advanced option later – for right now I can just right-click and pull up the property pages for the project, or double click on the WebSiteDeployment node (which is a short-cut for the same thing) to customize its properties.

There are several screens of information (the MSDN whitepaper will go into them all – for here I’ll just show a few highlights). One thing to note is that the settings are configured per-VS build configuration – so you can have one set of options for “debug”, one set of options for “release” and optionally define your own build configurations like “staging” and configure custom options for that build configuration as well. I’m going to change the settings below to apply for the “release” build configuration.

Here are a few of the more common things developers will want to control:

1) Developers can control whether to pre-compile the web entirely, or to support html source updates. Only the later option was supported in VS 2003 – and meant that you always had to deploy your .aspx source files on your production server (these were in turn dynamically compiled by ASP.NET at runtime the first time the app was run). ASP.NET 2.0 still supports this compile option (we call it the “allow updates” option in VS 2005). ASP.NET 2.0 also now supports a mode where you can optionally compile everything inside VS – including the .aspx/.ascx control definitions and html source. This produces a more efficient version of the app, and eliminates the need for a first-time dynamic compile performance hit when your app is run. It also allows you to protect more of the IP of your site, and enables you better compile-time checking of your application. The first property page in the web deployment project allows you to choose either this new compile mode, or the preserve .aspx source mode that VS 2003 used.

2) Developers can control what granularity of assembly output they want the website compiled down to, as well as what names to use for the assemblies (this is controlled on the output assemblies tab):

The default option is to merge the entire web-site into a single assembly that you can name however you want. This merges the output of all page/control compilation, app_code, and web-services into a single assembly (leaving one file to deploy).

There are other options you can choose as well for more granular control over the assembly generation. For example, the second option above lets you compile each folder in your website into a separate named assembly (for example: MyCompany.MyWebApp.Folder1, MyCompany.MyWebApp.Folder2). This is useful for patching large applications where you want to make a tactical update to just a portion of the site.

If you have an AssemblyInfo.cs/.vb class in your app_code directory, the deployment project will use the meta-data it contains to version the produced assemblies. Alternatively, you can also set the version information specifically in the IDE. This in turn saves it as an MSBuild variable in your project file. You could optionally use a custom MSbuild task to set this variable dynamically at build-time (for example: to use a policy like we do at Microsoft where the build number is based on the current date).

3) The developer can then optionally use the deployment tab for other common deployment scenarios:

One of these is the ability to replace the application’s web.config settings at build-time. This can be done on a configuration section by section basis. Simply list the name of the section to replace, and an XML file containing the replacement settings. You can choose to have them replaced either in-line within the web.config file (the default), or to use the new configSource attribute option in ASP.NET 2.0 to dynamically point the web.config file at external configuration files that contain the values.

Because all values in the settings dialog can be configured on a per-VS build configuration basis, this means that you can have one set of configuration file replacement settings per build configuration (for example: one connectionstring setting for “debug”, one connectionstring setting for “staging” and one connectionstring setting for “release”).

The other options included on this dialog is the ability to dynamically create and map an IIS vroot to the output directory as part of the build process, as well as the ability to delete the app_data directory as a post-build step (useful in cases where you want to delete the SQL Express database you’ve been using for development, and instead map your Membership, Roles, Profile, Personalization and HealthMon providers to a full SQL Server production database).

Step 4: Adding Optional Advanced MSBuild File Customization Rules

The above GUI property pages provide support for the most common build configuration settings. One neat thing about the Web Deployment Projects, though, is that there is easy IDE support for dropping down into the MSBuild file directly and customizing things further.

To-do this in the IDE, simply right click on the web deployment project and select “Open Project File”:

This will bring up an XML editor with intellisense support for the project file:

You can make changes, and then hit save to update things dynamically.

The web deployment project adds support for pre and post build events that you can use to customize things. For example, if you wanted to make sure a custom directory was created in your generated app after building, you could use the built-in MSbuild <MakeDir> task in the AfterBuild event:

</Target>

If you want to exclude a “Test” directory that contains some sample test pages from building in your release configuration you could add something like this:

</ItemGroup>

Note that you can use wild-card extensions when excluding things (above it is using *.* to exclude everything under the test directory) – so you can get quite fancy with your exclude rules. MSBuild itself ships with tons and tons of built-in build tasks (like MakeDir). The Web Deployment Project download adds support for another 40+ custom tasks specific to web application development/deployment. The really cool thing is that it is also easy to build your own MSBuild tasks and add them to projects as well.

Once you’ve made any custom tweaks, just hit save on the project file and close the window. Note that you can still use the property page dialogs above even after customizing the project file – it will preserve your settings and not blow them away.

Step 5: Building the Web Deployment Project

Now that I have my deployment project all setup, I can simply do a “Build Solution” to build all the projects in my solution – including my new web deployment project. This will then generate an output folder for my website. Contained within it is a \bin directory that has two assemblies (one for my data class library, and one for my web project):

The web.config file for my application has also been updated to have my production connectionstring settings.

One typical optimization that we’ll recommend would be to only build the web deployment project when your application is ready to be deployed – and not during actual development (instead when actively developing just work with the web project directly as normal). You can easily configure this in the VS build configuration manager:

For example: with the above settings we are configuring the WebSiteDeployment project to not build when the “debug” release configuration is set – and only do so when in “release” mode.

You can then use the build configuration drop-down on the toolbar to quickly switch between debug and release modes depending on where you are with the project:

Step 6: Optional Setup Project

One last bonus step that is also possible is adding a “Web Setup” project into our above solution. This is a standard VS 2005 project type that supports packaging a .msi file along with logic to create a vroot and deploy an application when executed:

I can easily configure the WebSetup project to pipe in the output from my WebSiteDeployment project into the MSI.

Then, while I select “Build Solution” again I’ll build my web deployment project, pipe it into the setup project, and I’ll be left with a .MSI setup program for my web application that will walk me through creating an IIS vroot and deploy my production app on a web-server when run:

Next Steps

Our plan is to post the first release of the VS 2005 Web Deployment Project for free download on MSDN this week. We'll then gather and incorporate feedback and release an updated version later this year.

We hope you find it useful. Let us know what you think and what additional features and MSBuild tasks you’d like to see added to it.

dipa ahuja replied to sushant kumar kesari

29-Sep-11 01:23 AM

The term setup is used for the windows application. For Website we use the term Deployment.

You can run your project by hosting in IIS

Step 1 : Build - > Publish Web Site

Step 2 : Publish it in the IIS server's folder : C:\inetpub\wwwroot

Step 3: Open IIS

Step 4: Expand the Root Node of the IIS in the left panel. In the Sites node you will get you published site

Step 5 : Right click on the your site and Choose Convert to Application:

Step 6: Now it will be converted to application Now Right click on it and choose Browse :

Done!

James H replied to sushant kumar kesari

29-Sep-11 01:30 AM

From your description, your project is ASP.NET website and the source files will be added to Web Setup project when you try to create Installer for it. So you want to protect your source files, right?