I am working on a web project as a Web Site, rather than a Web Application. How can I use a different config file depending on where it is hosted from, so the local version uses my local SQL install, but the published version uses the live database? e.g. connectionStrings.config ignored (not published), connectionStrings.live.config published as connectionStrings.config
I see a policy file option, would that be something able to do this?
There are several options regarding this. The simplest is to use a web deployment project. The ScottGu's post goes into more detail on this.
For larger projects you will need something like Nant or MSBuild and CruiseControl or TeamBuild.
I also posted something here a while back on supporting complex config deployments
Use a MSBuild or NAnt script for different builds.
You can use a Web Deployment project. Check out ScottGu's blog post.
Post Build Event which swaps the config over?
you can have a different post build event depending on your build configuration, each can copy a different config if needed.
Related
i am looking for a way to autodeploy a Dot Net Nuke website by TFS after checking in. I also need to some how transform web config to the right connection for the deploy server.
Since this is a website but not a web application, thing becomes tricky. If you have done it before, please give me some idea.
Thanks
I have not done auto deployment with TFS but did automate the process with SVN. What we did is simply have the script deploy everything that had changed since last login to the web server - EXCEPT - the web.config.
Database scripts were handled by a process like this but those were not as reliable as the SVN code deployment was.
HTH
You could use a deployment tool such as kwatee (self promotion). Kwatee is configured via a web GUI and can then deploy any application or site via python scripts and transform files along the way.
You can use Visual Studio web deploy feature. ALM Rangers shipped a ready to use BRDLite Reference template for this purpose which you can download here. Also, check this link for documentation for the template usage.
If you're using VS2010, you can use a Web Deploy Project in your solution. TFS will talk to the WDP as it would with a web application's project file.
For config transforms, you can use a tool called SlowCheetah.
We practice continuous deployment with TFS (2008) and are looking for a nice way to handle IIS settings changes. MSDeploy seems like it should be the way to handle this, but after much reading and searching, I haven't found a good answer.
The problem with MSDeploy, as I see it, is that you need to create a deployment package using an existing IIS website. I would like to be able to have the appropriate IIS configuration for the website in source control and have the build create the package.
The only way I can see to do this is to hand craft the archive.xml file. Is my thinking correct or is there a better way?
I ended up using powershell web administration module (with PSake for the build) to do this. I would still prefer to do this in a declarative manner.
I've been able to put a bunch of the website settings into my web.config so that they are in source control and easily deploy-able. Not all though. Some seem to get set higher up in the IIS hierarchy and then cannot be overridden by my web.config.
I've never found a way to do this with application pool settings.
For setting up new sites I wrote a small C# WinForms app that uses the programmatic interface to IIS to create the sites and app pools and change their settings. Probably similar to your PowerShell script.
I have an ASP.NET application and i selling it to different companies. I change the application settings according to the company information and publish the whole application to a output folder. And then take the output folder to clients machine with necessary dlls(My application dll and few third party dlls). I am wondering if it is possible for anyone to decompile the code from the dll's in bin folder and get the application code? Is there any standard process i need to follow so the my code are safe in client server.
You would need to obfuscate the dlls created for your project, but there are some issues with that related to ASP.NET. See this stackoverflow post
Enjoy!
Yes.... And see other answers for how to avoid it.
You can also try Redgate's SmartAssembly
Rather than Xcopy deploy, you should look have a look at web deployment projects for your deployment - http://msdn.microsoft.com/en-us/magazine/cc163448.aspx.
If you need to protect your assemblies from reverse engineering, you need to look at an obfuscator like http://www.preemptive.com/products/dotfuscator/overview
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?
When I build my ASP.NET web application I get a .dll file with the code for the website in it (which is great) but the website also needs all the .aspx files and friends, and these need to be placed in the correct directory structure. How can I get this all in one directory as the result of each build? Trying to pick the right files out of the source directory is a pain.
The end result should be xcopy deployable.
Update: I don't want to have to manually use the Publish command which I'm aware of. I want the full set of files required by the application to be the build output - this means I also get the full set of files in one place from running MSBuild.
One solution appears to be Web Deployment Projects (WDPs), an add-on for Visual Studio (and msbuild) available that builds a web project to a directory and can optionally merge assemblies and alter the web.config file. The output of building a WDP is all the files necessary to deploy the site in one directory.
More information about Web Deployment Projects:
Announcement on webdevtools MSDN blog for WDP 2008
ScottGu introduction to WDP 2005
The only disadvantage to this solution is the requirement on an add-on which must be available on the build machine. Still, it's good enough for now!
ASP.NET doesn't have real xcopy deployment for new sites. It depends on having a virtual directory/Application in IIS. However, once that virtual directory is created you can use xcopy for updates.
You can Publish Web site..If you want to automate your deployment, you need to use some script.
Have you tried using the aspnet_compiler.exe in your .net framework directory? I'm pretty sure you can create a "deploy ready" version of a web application or web site.
The _CopyWebApplication target on MSBuild will do exactly what you need. The catch is that only the main assembly will be copied to the bin folder and that's why a copy task is needed to also copy any other file on the bin folder.
I was trying to post the sample script as part of this post but wasn't able to.
Please take a look at this article on my blog that describes how to create a MSBuild script similar to the one you need.
Have you tried right clicking the website in Solution Explorer and clicking 'Publish Website'?
Build --> Publish
A dialog box will appear that will guide you through the process.
For the automated building you describe in the update, I would recommend you look into MSBuild and CruiseControl.NET
It depends on how complicated solution you need, you could just use a script and jenkins for example. You can use MSBUild with Jenkins for just deploying to an IIS. And if you got Jenkins other tools is pretty easy to connect into it later on. But if you just want to build, use a script that jenins execute every build that uses MSDeploy and it will work great.
This is how i do it, just to give you a feeling:
Sonarqube uses Gallio, Gendarme, FXcop, Stylecop, NDepths and PartCover to get your metrics and all this is pretty straight forward since SonarQube do this automatically without much configuration.
Here is Jenkins witch builds and get Sonar metrics and a another job for deploying automatically to IIS. I use a simple script one line that calls my MSBuild and wich URL, pass and user.
And Sonarqube, all metrics for my project. This is a simple MVC4 app, but it works great!:
If you want more information can i provide you with a good guide.
This whole setup uses MSBuild, too build and deploy the apps.