I am working on my first ASP.NET MVC 4 app. The client is deploying directly from the SVN repo, which I am pushing from. Can/should I be checking in release builds, or should they be running builds on their end as part of the deploy process. I am wanting to make it as simple for them as possible. Thanks for any advice!
You shouldn't be checking any builds into a source control repository. Only source code. A build server should be used to precompile the application using the target configuration (Release if you are pushing to production). Also be careful not to leave any production connection strings and urls into the source code you have commited. An innocent developer could checkout the code and do lots of damage without any consciousness.
Related
We're trying to move a fairly complicated set of web applications from .NET 4.5 to .NET 5.0, hosted in IIS.
One problem we need to figure out is how to manage the per-environment configuration, during deploys.
With .NET 4.5 we are using web deploy packages. The production team already has hundreds of xxx.SetParameters.xml files for the many customers and environments.
In dev and test, we're using appsettings.%ASPNETCORE_ENVIRONMENT%.json, but that's not going to work for our production deploys.
The production team would like to continue using web deploy packages with xxx.Parameters.xml and xxx.SetParameters.xml files, so they don't have to reconstruct them in some new mechanism.
We're fine with telling them they have to change, if they really do have to change.
How are per-environment configuration settings usually managed, in asp.net 5.0?
Some additional clarification.
In our existing process, a build generates a deployment package.
A deploy to a particular environment then takes that package and a file defining the configuration for that particular environment, and creates a site and applies that configuration.
This is currently using msdeploy, but that's not important. What is important is that the per-environment configuration files are maintained in a separate repository, and are not stored with the source code.
And we don't want them to be.
The change history of the per-environment configuration files is completely unrelated to the change history of the source code used to create the deploy packages.
I am developing a C#, MVC4, EF5 Code First application on .NET in Visual Studio 2012 and have used the VS publish mechanism to deploy it to an Azure Website with an Azure SQL Database.
I now want to use Git and GitHub for version control and involve others in the project.
However, although I am familiar with using Git in a LAMP environment, I have no experience of using Git with Windows, Azure Websites and a compiled environment.
I would like to use the Azure Website as the production server, another Azure Website as a Staging server, developer Windows machines using Visual Studio for development and GitHub as the central repository.
There is a helpful article here: http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-git/ . I can get my head around what would be needed here for, say, a PHP application on Azure. But I am unsure of the best approach with a compiled application and what I can achieve using Azure Websites and Visual Studio.
A nudge or two in the right direction would be greatly appreciated!
don't publish from VS to azure, instead setup your azure website to pull from the github repo. the deployment process compiles your solution.
watch http://www.youtube.com/watch?v=5NGieL0tinw&feature=youtu.be&hd=1 or read http://vishaljoshi.blogspot.com/2012/09/continuous-deployment-from-github-to.html
Also SocttGu announced this on his blog # http://weblogs.asp.net/scottgu/archive/2012/09/17/announcing-great-improvements-to-windows-azure-web-sites.aspx he also talks about a cool feature of publishing branches, this will nail your requirement for a stage server and production server. Have a stage branch and a production branch and merge to them as desired. see the section "Support for multiple branches"
looks like they added support for private repos finally.
appharbor is a competitor to azure that does something similar.
You are basically introducing a new step with the requirement that the source code must be compiled before it can be deployed to the server. Where you implement this step is up to you. You could:
Ensure that your target server has the capabilities to compile the source code (some Continuous Integration tools could help with this, such as CruiseControl.NET). This has the caveat that the target server be able to compile source code (possibly even requiring Visual Studio to be installed), so that may not be an option.
Check the compiled binaries into source control. You could keep these compiled binaries separate from the main source branch, to keep things clean. Deploy the binaries to the target server.
Some hybrid of the previous two options is also possible; you could set up a Continuous Integration server with CruiseControl.NET, which can check out the current source, build it, and check the resulting binary back into a special branch, then deploy that branch to your target Server.
I have an asp.net application that I currently deploy to 4 different environments on the client's servers. At the moment we deploy by copying over individual assemblies and content files but the whole process is time consuming and error prone. Basically I'd like a method of preparing the application for deployment that will give me a folder containing the application (no source code etc). No IIS changes are required. It would be good if I could specify different webconfigs for different environments.
I've looked at msbuild, msdeploy, etc and I'm not even sure which is the right tool for the job. I'm tempted to go with a batch file that copies only certain file extensions but I'm sure there must be a better way of doing this. Any help please?
Take a look at the Visual Studio Publish Web Site feature.
I come from a PHP/Rails background where deploying a website often means FTP/Checkout of the source code in the correct directory on the web server.
However, I've been asked to develop an ASP.NET website and some people have advised me to "Publish" the site instead of copying over the source code directly. Apparently, this converts the codebehind (.cs) files into compiled DLL's etc.
My application does not contain any specific secretive business logic. It's a common shopping cart app. My question is if this is a good idea? How does not making the C# code reside on the server make the app more secure?
ASP.NET code will always be compiled - either:
At run-time - you can copy .ASPX and
.CS files to the server. When a page
is requested the .ASPX and .CS files
will be compiled on-the-fly. The
ASP.NET run-time will create a DLL
containing the compiled code (this
lives in a folder called Temporary
ASP.NET files and the location
depends on the version of .NET
you're using).
Pre-compiled - you can choose to compile your code before deploying it to your server. This is what the Publish command does in Visual Studio. It compiles your .ASPX and .CS files into (one or more) DLLs that are then uploaded to the web server.
Personally, I don't think there's much of a security benefit from deploying pre-compiled code (unless you're obfuscating your pre-compiled DLLs).
That said I prefer it for these benefits:
It seems tidier, at least to me, than having a bunch of .CS files littered in a folder
There's a small performance benefit of not having to do C# compilation. Note your code will still need to be JITed from IL to native code and this still incurs the initial request performance hit (unless you use new ASP.NET 4.0 and IIS 7.5 features or something else).
The Publish feature lets you package your application up for deployment to other environments (testing, pre-production, production, etc.)
Note: coming from Rails/PHP you might like to keep on deploying both .ASPX and .CS files to your server. The benefit is that it's easier to modify a running application in a way you may be used to doing. This isn't a great practice if you're following a rigorous deployment lifecycle but it can be useful in some cases.
I can make one addition to the precompiling though, which has been mostly about security and performance; compiler checks!! Without precompiling you can easily upload some code file containing errors but not find out before 13 days later when the first user hits the page using this code-file. This is due to the fact that asp.net will only compile one file at a time whenever its needed.
With precompiling ALL the files will be compiled and ALL compiler errors be caught right away.
Thats all about precompiling though but publishing is not just about that.
Another important factor is the steps you can instruct msbuild to execute during publish. Maybe the most important thing is web.config transformation which you can read about here http://msdn.microsoft.com/en-us/library/dd465318.aspx. Basically you can create a transformation file that during publishing will replace/add/remove values from your web.config based on the publishing target.
Your c# code is still residing on the server, it's just residing as a compiled code instead in the form of a script as you are used to in PHP/Rails.
In PHP, rails or classic ASP, you write scripts and xcopy / ftp to your webserver. PHP interpreter then parses the script everytime a web request comes in vs. in asp.net the code is compiled and then copied to the webserver, so when a web request comes in, the execution is much faster.
Think of it broadly as deploying an .exe file on the server vs. writing the program in a text file and making a compiler parse the text file and running it every time.
It has nothing to do with being more secure or not.
Btw - How's life after Bluebells School :-)
Yes, it's more about compiling than anything else. For the website to be able to run, the C# code must be compiled and that is what the publish step does, together with transferring it to a specific location.
The version of the website you have on your desktop is a development version, most likely with debug versions of the compiled code. With the publish step however, you should generate a release versions of the compiled code which also improves performance.
The publish step of ASP.net can be compared to creating an installer of a normal Windows application and, when published to an operational server, the install step combined.
What is the best strategy for making changes to a specific file within a C# .NET project and a DEV server and then moving that file to a different environment, say server B? I noticed it always wants me to recompile on the destination server and I figured I was doing something wrong because I didn't think I would have to (plus the server isn't in-house so it is really slow and time consuming).
Any suggestions or strategies you or your company uses would be appreciated.
Make sure you are using a Web Application project where it compiles a DLL, not web site which uses loose code files.
You could use a source code versioning system like Subversion.
use a source control program for source files (like SubVersion) and Cruise Control for binaries built out of those files...
For web application development my experience has been:
Developers have a development environment on their local machines that is attached to source control
A DEV web server with shares to the projects created allows developers to COPY files to the web application folders manually.
A TEST web server where MSI installations ONLY are used to distribute the changes for UAT
A PROD web server where MSI installations ONLY are used to distribute the UAT approved MSI
The size of projects I am involved with usually makes build scripts overkill, most times a project is being worked on it is built many times for debugging etc.