Automatic deployment of ASP. NET MVC Web site project with PowerShell (i)

In this article we will write some code about automated deployment. We'll use Powershell to write this type of code.

You will find that the articles in this article are very specific, some of them are even very demanding and may not be universal. This is because the deployment has always been to the environment, the deployment process of collaboration in the formation of too many, the intersection of each other can not be too large. Perhaps the only thing that can be generalized is the basic principles of automated deployment (just the basic principles of this article):

• After each automated deployment, the application will have the same initial state.
• Automated deployment of machines is very clean, with only the appropriate Windows Server system and the . NET Framework. In particular, there will be no Visual Studio.

We need to disclose some basic environmental information:

• 64-bit Windows Server 2008/2012/2012 R2 or 64-bit windows 7/8/8.1
• Our project was developed using Microsoft Visual Studio ;
• The . NET Framework version is 4.5
• The version of ASP. NET MVC is 5.0.0
• The version of Microsoft build Tool is 12.0

There's a few more words to say about MSBuild here. Before Visual Studio 2013 was released,MSBuild was released with the . NET Framework . This means that we can build. NET applications without having to install Visual Studio .

What a wonderful world it is! Therefore, the last sentence is false. Especially when you build an asp . NET Web application, you will soon encounter "cannot found ... Webapplication.target "error. If you stackoverflow, you'll know that all we need to do is install Visual Studio or copy the relevant files from another machine that has Visual Studio installed. This is--embarrassing design! Linux fans have a space to vent.

So Microsoft decided to face up to the problem. Beginning with Visual Studio 2013,MSBuild will be published with Visual Studio instead of the . NET Framework . It drew a curse. I have to say that in life, no matter what you have to keep calm enough, often first temper the lack of any benefits. The fact is that because the . NET Framework releases are relatively lengthy, Microsoft is increasingly inclined to use NuGet for Class Library publishing, which helps to reduce the size of the . NET Framework base Class library. And shorten the release cycle of the base Class library. The release cycles of the corresponding MSBuild and Visual Studio also want to change independently. MSBuild will maintain the consistency of the release cycle with Visual Studio and does not imply that this MSBuild relies on Visual Studio. So of course we can download the standalone installation package for MSBuild , Microsoft build Tools, and automate the build on a server without Visual Studio .

Again, if you're lucky, you can run the example directly in this article. But you should not expect to copy the script from this article to your project to work properly. Because deployment is a local task, it needs to be analyzed in detail. You may encounter a variety of environmental problems, but I think the most important thing is thinking.

What is Deployment

Simply put, the deployment is "build" –> "Copy" –> "Configuration". Then we'll start one and fix it. This article will focus on building.

Compiling and building Applications – ideas

How do I build an application? The answer is to copy everything you need before you build it with tools. Great, what do we need to copy? Copy the source code first, of course.

┌────────────────┐│ Src of MyApp │└────────────────┘

The source code is not working because our program relies on third-party libraries (arrows represent dependencies).

┌────────────────┐│ Dependent libs │└────────────────┘ ↑┌────────────────┐ │ Src of MyApp │└────────────────┘

For example, for the simple ASP. NET MVC 5 Application We built, we need to download the class library it relies on before building:

• MICROSOFT.ASPNET.MVC 5.0.0
• Microsoft.AspNet.Razor 3.0.0
• Microsoft.AspNet.WebPages 3.0.0
• Microsoft.Web.Infrastructure 1.0.0.0

The source code and the dependent library are all copied, then we need to copy the build tool as well:

┌────────────────┐│ Dependent libs │└────────────────┘ ↑┌────────────────┐ ┌───────────────────┐│ Src of MyApp │────→│Tools for compiling│└────────────────┘ └───────────────────┘

For us, there is only one tool to build:

• Msbuild

Now the tools, the source code is readily available, we can start compiling.

Installing MSBuild

If you have a Visual Studio version of 2013--express installed on your lab machine, you can skip this step, otherwise download Microsoft Build Tools and install it.

Download the application's code

Our code is out of the box, just need to clone it from Git repository. You can also clone from this address to a sample code and switch to the corresponding commit.

git clone https://github.com/lxconan/MvcFromZero.gitgit reset --hard 340abb32433c99975bd6485f79db6ca077119477

Well, done, so far everything is so relaxed and happy.

Download the app's dependent libraries

We will use the NuGet Management Pack dependency. So we'll first download the NuGet command-line client, which can be downloaded from here.

The next behavior requires a clear directory structure. For illustrative purposes, we will establish the following directory structure.

MvcFromZero |- src | |- FromZero.App | |- packages | |- build |- tools

Where the SRC directory holds the source code for solution, and the build directory holds the various tools and scripts needed to build the automation. The tools required for automated builds will be placed in the Build/tools directory. So we will also put Nuget.exe in this directory.

Next we build the Deploy.ps1 script in the build directory, and we will do the next task in this script. Let's download the dependent package first. The package management of NuGet is done through the package.config file. It should be pointed out that Package.config also has a certain level of relationship. First, the solution level of package information is stored in two places:

• The first is the . Nuget/package.config file in the solution directory, which stores the packages used for non-specific items (if there is no such type of package, the directory does not exist, or there are no files in that directory);
• The second is the packages/repositories.config file in the solution directory, which stores the path to the packages.config file for each project under the solution.

The package definitions for each project under solution are stored in package.config in the project directory.

Is it necessary to manually traverse these config files in order to download these dependent packages? The original is, and starting with NuGet 2.7, can directly support the solution range of package download, so we can use the following simple function to complete the download of the package.

Function Install-SolutionPackages() { iex "$global_nugetPath restore $global_solutionFilePath"}

Where is the path $global_nugetPath to the Nuget.exe, and the path to the $global_solutionFilePath project file (here is FromZero.App.csproj).

The next thing to be sure is the location of the build tool, we can use the registry to find the location of MSBuild , because we used the 2013 version of MSBuild(Toolset version number 12.0), so our find script is:

function get-msbuildpath () { $msBuildRegPath = "hklm:\software\microsoft\msbuild\toolsversions\12.0" $ Msbuildpathregitem = get-itemproperty $msBuildRegPath -name "MSBuildToolsPath" $msBuildPath = $msBuildPathRegItem . MSBuildToolsPath + "msbuild.exe" return $msBuildPath }

Once these two steps have been completed, we can compile our project:

Function Compile-Project() { iex -Command "& ‘$global_msBuildPath‘ $project_path"}

You can't wait to experiment with your code, but there's a problem, andMSBuild reports that it can't find the Microsoft.WebApplication.targets file. What's going on, we've already installed Microsoft.WebApplication.targets in MSBuild ? This is because in order to maintain compatibility with the engineering of Microsoft Visual Studio SP1, the project forVisual Studio 2012/2013 defaults to $(VisualStudioVersion) setting the environment variable 10.0 . In this way, the query path to the target file is:

$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0

Instead of:

$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0

So we need to fix this environment variable. Please use a text editor to open the FromZero.App.csproj file and find the following definition:

<PropertyGroup> <VisualStudioVersion Condition="‘$(VisualStudioVersion)‘ == ‘‘">10.0</VisualStudioVersion> <VSToolsPath Condition="‘$(VSToolsPath)‘ == ‘‘"> $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion) </VSToolsPath></PropertyGroup>

Replace the section with the VisualStudioVersion following:

<VisualStudioVersion>12.0</VisualStudioVersion>

Run again: Congratulations, you have been able to successfully download all the dependencies and complete the project compile! At the end of this article, attach all the code DEPLOY.PS1 so far:

$ErrorActionPreference=' Stop '# Environment Helpers------------------------------------FunctionGet-msbuildpath(){ $msBuildRegPath="Hklm:\software\microsoft\msbuild\toolsversions\12.0" $msBuildPathRegItem=Get-itemproperty$msBuildRegPath-name"MSBuildToolsPath" $msBuildPath=$msBuildPathRegItem.MSBuildToolsPath+"MSBuild.exe" Return$msBuildPath}# Environment Variables----------------------------------$global _builddirpath=Get-location$global _msbuildpath=Get-msbuildpath$global _solutionpath="$global _builddirpath\. \src "$global _solutionfilepath="$global _solutionpath\src.sln"$global _nugetpath="$global _builddirpath\tools\nuget.exe"# Install NuGet Packages---------------------------------Functioninstall-solutionpackages () { IEX "$global _nugetpath restore $global _solutionfilepath" }< Span class= "line" > $project _path = $global _solutionpath + ' \fromzero.app\fromzero.app.csproj ' Function compile-project () { IEX -command "& ' $global _msbuildpath ' $project _path '" < Span class= "p" >}install-solutionpackages Compile-project