Monday, June 27, 2011

We’ve setup a NuGet Gallery and now we wanted to have our builds automatically package and publish to the NuGet Gallery.

The below is more or less the step-by-step process to get it up and running in an automated way.

Step 1 Create your NuSpec for your .csproj. The documentation on NuGet documents is pretty good for this step.

The gist is you will need to have the .nuspec file in the same directory as the .csproj file. You will have to modify this file and ensure you’ve populated all the correct tags as mentioned in the NuGet documents.

Note: An error message will appear when trying to package if something is missing.

Step 2 Modify your .csproj file and add the below snippets. They are generically written so they should fit right into your msbuild file fine. Obviously, edit when appropriate should your msbuild file already be customized.

Edit: Make sure you update the My_Nuget_Gallery_Service_Url token in the script to point to your gallery.

Note: You will need to run nuget setApiKey before this will work as it relies on the API Key for the NuGet Gallery already to be stored locally. This is handy as you can login as your Build Service Identity and run the command. It will then publish as that user from then on out.

Step 3 Run it via MSBUILD.

All you need to do on your build sever is execute the below command:

Edit: Make sure you update the tokens to be the correct values for your project.

Friday, June 10, 2011

I wanted to jot a couple notes about the process which took me a few minutes to figure out.

Step 1 is setup and configure Package/Publish Settings.

Open Visual Studio 2010

Open your Web Project

Open Solution Explorer

Right-Click on your Web Project

Click on Package/Publish Settings

At this point, you should see the below.

You need to make sure you set the “IIS Web site/application name to use on the destination server” to the «Web Site»/«Virtual Directory» path. If you are updating a Web Site just leave it to be the web site name in IIS.

This is very important. If this doesn’t match the target, then your deployment will fail unless you customize the deployment further.

You’ll want to repeat this process for all your difference Configurations. By default, Visual Studio gives you Debug and Release. Most people, will add one per environment to the list (i.e. Development, Integration, QA, Staging, Production, etc.)

Step 2 add a Parameters.xml file to the root of your Web Project in Visual Studio 2010. This allows you to setup parameters, which the deployment process will use when it’s processing your deployment. An example of what I used is below.

Parameters.xml

<?xmlversion="1.0"encoding="utf-8"?>

<parameters>

<parametername="Application Path"

description="Full site path where application will be created."

defaultValue="$(DeployIisAppPath)"

tags="IisApp">

<parameterEntrykind="ProviderPath"

scope="iisApp"

match="$(DeployIisAppPath)"/>

</parameter>

<parametername="Application Physical Path"

description="Physical path where files for this Web application will be deployed."

defaultValue="c:\inetpub\wwwroot\$(DeployIisAppPath)"

tags="PhysicalPath">

<parameterEntrykind="DestinationVirtualDirectory"

scope="$(DeployIisAppPath)"

match="" />

</parameter>

</parameters>

You’ll note I used $(DeployIisAppPath) several times within the file. This refers back to the “IIS Web site/application name to use on the destination server” setting in your Package/Publish Settings in your Web Project.

Note: At the point of this writing, I haven’t experimented much with these settings, so feel free to tweak away.

I’m running on 64-bit Windows, so my Framework folder is Framework64. You might need to change this if you’re running 32-bit Windows.

I’m telling msbuild to run Build and then Package with the /t argument. Case sensitive.

I’m telling msbuild which configuration to run with /p argument.

I’m telling msbuild where to put the package by specifying the DesktopBuildPackageLocation with the /p argument.

Feel free to tweak this away it was hand to get something going on my side and may or may not be helpful to you.

After you run either of the above, you should have a package zip file and several other files in the directory.

Note: If you copy the package zip around you must include the other files with it to get the deploy to work correctly, so don’t forget them.

Step 4is go to your IIS target server and setup the Web Site or Virtual Directory. Ensure you setup the name of the Web Site or Virtual Directory to match the one you populated in the Package/Publish Settings in your Web Project.

You will need to ensure you .NET Framework version is configured on your Application Pool to match your web sites target framework.

Note: The web deployment does not initially create the Web Site for you on the destination server. This must be done by other means.