I need to create an installer program that will do install the following:
1. ASP.Net Website
2. Windows Forms application
with prerequisites(SQL Server 2008 express, .net Framework, IIS)
Both are under the same solution,
they share the same libraries and layers (data layer, business layer, etc)
So I'm facing a problem, because I think I should create 2 installers, one for the windows project and one for the web project, but this approach has a problem, it will create a data layer, a business layer and a common layer for each project, so if I want to update a layer, lets say I modified the data layer and I want to update it, I'll have to update both, so it occurred to me install those libraries in the GAC, but I don't know how to do it.
I also don't know if it's a good idea to create two installers, or if it's possible to create only one.
So basically the question is, do you know how to deal with:
shared libraries
Windows and web applications under the same solution
Prerequisites
IIS perms and configuration (pools, users, virtual directories)
all that inside the installer
We can buy installshield or similar if needed,
Thanks !!
I have worked on many projects with similar shared code block as you have neatly drawn out.
Experience has taught me to go with separate installers as you may want to update a single part of the client application, for instance, adding a couple of user option fields to the database and win forms application, which does not need an immediate rebuild of the web application.
With regards to installation, I would go with ClickOnce deployment (Click Once on MSDN) it's built in to Visual Studio, check out your project properties. It is easy to build, incorporates any pre-requisites you may have and can be installed from a central location. To update all your users, you simply click the publish button and they all have the latest version on next run.
I too would stay away from the GAC it is not worth the hassle.
Whether you should have one or two installers is really more a function of how your product will be used. If these two should always be installed together, a single installer seems to make more sense.
The MSI project in Visual Studio is very limited. VS2010 has InstallShield LE, but it's pretty cripped. I would try using LE, and buy InstallShield 2012 only if I had to (it's pricey).
As for the GAC, I would stay away unless your libraries will be shared across other products.
It will be hard to create a single installer for both program. You will need to customize the msi installer for the winform application and execute the webSite Installer packaged in the msi. Try first to do two installation system before combining them.
Related
I've Googled, Binged, and here at StackOverflow, looked through the related questions and searched, but I'm not finding what I'm looking for. I've also searched documentation on DNN.
What I'm looking for is any guidance (tutorials, blogs, step-by-step instructions for setting up a repository) etc from people who are experienced in using DotNetNuke with SVN.
We use SVN for all our source control, and have no problem with standard applications, because we pretty much built the repository and directory structure to work with our processes. This means when we do web sites, in Visual Studio, we do file based web sites, rather than setting them up in the local IIS. It just makes things easier for us.
However, with DNN, it appears that even if you get the source code, it is expecting to be set up in the local IIS, which means additional headaches for us.
For example, we are moving all of our source code off our local C drives, and onto a shared drive on a server. This is to enable backups in addition to our normal source control. (This was a management decision). So that means that we need to change the virtual web app when we make the move.
Has anyone come up with a good way to work around this? Can DNN be set up so that the developer web server in Visual Studio can be used, so that we can treat it just like any normal web app? Am I missing something obvious?
Source Control
I recommend using separate projects for DotNetNuke projects (skins, modules, providers), and not checking the actual web site itself into source control environment (DNN Modules would use the WAP style project). Each developer could then have their own DotnetNuke site and database in their development environment. I also don't recommend making changes to DotNetNuke's core so that you have a clean upgrade path. I would recommend using a tool such as Red Gate's SQL Data Compare in order to generate database scripts for your data that you could keep in the source control environment as well.
Here is some more information about setting up a Web Application Project for a DotNetNuke module.
Testing/Staging/Production
Keeping these separate in DotNetNuke is generally very easy because you're already creating modules that plug into a DNN site. My recommendation is to create packaged and properly versioned modules so that you can cleanly install them on test, staging, and production.
You may want to investigate building module packages with MSBuild scripts. Alternatively, Here is some information on using NAnt to automate DNN module packaging.
Which is the best method to deploy a web application. Currently i am publishing the application and placing that folder in the server and creating virtual directory and providing windows authentication.
I just want to know this is a better metod to deploy or i need to use any other deployment technique?
Plese suggest
It really depends on the situation. For some situations, using Visual Studio's publish feature (right click project) works great. However in some situations, particular larger organizations or environments where the infrastructure group and development team are a little more isolated, you need to use a Web Application Installer or an MSI package. I've also had instances where the easiest thing to do was create a simple .bat file and create an external command in Visual Studio.
Use a web application installer, easy to create with Visual Studio.
If you need a third person to deploy your application in production servers, I would suggest you to deploy using a MSI, it would also help you to version your release.
MSI can be created using various ways including but not limited to
Deployment projects in VS studio
WixGen
Click once
Currently, I'm maintaining an older ASP.NET website. In the solution, there exists 5 C# projects which build to assemblies as well as the development server's web directory. Normally, I do whatever work needs to be done (adding pages, making changes to existing projects, etc), build the projects (the current output path is my development server's wwwroot\bin\ directory) and if all is well, I open Windows Explorer and drag either .aspx or .dll files from the dev server to the production server. It's that last step that I'm wondering if there is a better way of doing. Does anyone have a different way of doing things where you don't have to leave Visual Studio to push updates?
You should add a Web Deployment Project, that´s (in my opinion) the easiest/best way to deploy a Asp.net app
Here´s an interesting article from the MSDN Magazine. http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
ASP.NET Web Site Precompilation Overview would seem to be what you are wanting, yes?
Otherwise, there are web deployment projects for VS 2005 and web deployment projects for VS 2008 if you want a couple of alternatives depending on which version of Visual Studio you use.
How old is older? Are you using ASP.Net 1.0, 1.1, or 2.0, as those are what I'd consider older, but then I've been doing web development for over a decade.
You might want to consider creating a build script and a deployment script. You can look at using either Nant or MS Build, which are popular, or simply go with a batch file approach.
Some of the reasons I suggest going with scripts are:
1. You'll never forget to push that one file that you added
2. Either your build script or your deploy script should create a copy of all the artifacts need for deployment. This way, if you push out a bad build and need to roll back for whatever reason, guess what, you have a working copy tucked away somewhere.
3. Your scripts can run the installers (if you created a setup project) or they can simply copy out the files to the correct location, so that you don't have to have your dev box pointing to the right folder.
4. Sometimes you need to make changes to the configuration before you deploy... your scripts can also do this for you.
In general automating the whole process just makes it easier, faster and repeatable.
I'm a total newbie to SVN and haven't been able to find an answer for the following situation.
I have an ASP .NET 2.0 web app that I am developing. I am using my local IIS as the development web server (i.e. not the Visual Studio web development server). My development environment is VS2005, Vista, IIS7, TortoiseSVN / AnkhSVN. VisualSVN is installed on the server.
My .sln files and class libraries, etc. are located in the **C:\Localsource\Projects\ProjectName** folder, and my .aspx files are in my **C:\inetpub\wwwroot\ProjectName** folder.
I can set up the repository for **C:\Localsource\Projects\ProjectName** fine, but can't think of a way to set it up for the IIS folder as well in the same repository.
What's the best way for dealing with this development environment in SVN?
Many thanks,
Ant
In a solution in Visual Studio you can have a class library project which is usually in a directory underneath the .sln file.
In this case he also has a web project within the solution but NOT underneath the .sln file in the file directory structure.
He will be attaching to this project via HTTP not via local file path.
IIS will manage this as http://localhost/webapp and by default will place it in c:\inetpub\wwwroot\webapp. The files in webapp folder will not be in the repo as they arent in the hierachy of the solution and the class library. This is his question how to sort it out.
My answer is to move http://localhost/webapp to point to a folder that is underneath the .sln file and adjacent to the class library directory then it can all go in the repo.
Seperating the class library and the the webapp is best practice to aide code re-use and decoupling the logic from the web site.
Can you not just point IIS to C:\Localsource\Projects\ProjectName and set the permissions?
Hmmm - Good point. It was set up like this when I got here, and Visual Studio always creates websites in the wwwroot folder, so I assumed wwwroot was just where they had to go.
Maybe I'll have to think about doing a little rearranging...
Thanks!
The IIS folder is not the output of the code base it is part of the application. It's not CGI output or anything but actually the scripts to run the app!
This is the .aspx pages that will have user controls and HTML to actually run the application. Its part of the applciation but split away from VS Studio solution.
The easiest way is to have a solution and then C:\Localsource\Projects\ProjectName\WEBSITE.
Point IIS at that folder as well.
OK, I may be being stupid here but.. Why do you need to add the IIS folder (i.e. the output of the code base) to your repository?
Update
I think I should clarify this a bit more.. What I mean to say is I am not sure why the ASPX is seperate from the project anyway? What is wrong with an Web Project and n Class Library Projects in a Solution, added to your repository.. You then publish on each new release..
If it is simply a case of "it might be easier to roll back the published output" then so be it, I was just curious as I have not seen many people actually work that way.
Deployment of solutions in this structure would be a lot easier as well..
I think you might want to separate this into two problems, following this recommendation from Dillorscroft.
First, with regard to the material on your development server that is published to the production site, I think you need version control for that. First so you can roll back any page, and you can also decide when you have a stable level of the development site that you want to extract to production. (I would get that from the source control system into a site image and then synchronize that image with the production site.)
So, for the first part, we are talking about versioning the web pages and all of the custom server-side material that supports the web site.
Secondly, With regard to the development of components that are used on the site, they need their own development projects, since it is the result that goes to the development site, not all of the source, libraries, etc. that the component is built with. So these will have their own project development tree (think of it as if you were building a library that is to be used by other development projects, although in this case the other projects are web pages). So the only thing that should show up in IIS is the "deployed" component to the development site.
There seem to be three critical questions for you:
How development of tests that need to go against the web site is handled and where that is version controlled (assuming they do not belong on the web site itself)
How easily you can arrange to make sure that all content on the development web site is kept under version control and checked-in and -out appropriately. (This has to do with the tools you use to edit web pages and other server-side gunk other than components developed off to the side.)
Easily taking developed components from the projects that produce them to the development site and have them be checked-in there.
My solution to (2) and to version control of the development web site is to use Visual Source Safe integration with IIS and FrontPage extensions that places the site under version control. Components produced from other development projects are mapped to the server project by VSS sharing.
For SVN, I speculate that (1) you want to see if there is an SVN adapter that IIS will recognize as an external source-control system and, either way, (2) have a discipline that takes delivery of components from their construction projects into the overall web site project.
Rob,
Why do you consider an .aspx file an output of the code base?
It is part of the code base. It's not an output after compilation for instance.
Just wondered?
Applications I am using:
Visual Studio 2008 (C#/ASP.NET)
Visual Source Safe 8.0
IIS 5.1
I have two Web Apps both named the same but one is used for major releases and the other is for minor (trunk and branch). I am wondering if there is an option in Visual Studio that prevents it from creating an ASP.NET app in IIS using the web app's project name. Since both of them are named the same I have to go into IIS and change the path of the application so that it point to the major (or minor) folder when i go between the two.
What I would like to do is have something like this:
http://localhost/webapp_major
http://localhost/webapp_minor
but the web projects still have the same name. I know I can go into the properties of the each project file and have them point to different places but I think that breaks something when you want to merge between the two.
Any Ideas would be very appreciated.
Instead of having HTTP based projects in your visual studio solution, add them as file projects, where the website will be accessed as c:\inetput\wwwroot\major_version (for example) in visual studio (and not http://localhost). That way you can have any kind of setup you want in IIS and your projects won't conflict when you merge them.
Your web application project will let you name the Virtual Directory anything you want. VS2008 extends this by allowing you to set this on a per-user basis, so this information won't be saved in the project file, and therefore won't be propagated to source control.
You can manually create a new web application in IIS and let it point to your working directory. Visual Studio should honor these settings.