Deploying Web Applications on a remote IIS server using MSBuild

I have written down some important points that should be taken care while deploying applications. Hope it helps others trying to do that same.

Ø  MSBuild arguments should be set correctly.

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:MSDeployServiceURL=<web server name>:8172/msdeploy.axd /p:DeployIISAppPath="<Website Name>/<Application Name>" /p:CreatePackageOnPublish=True /p:AllowUntrustedCertificate=True /p:UserName=<Domain name>\<User Name> /p:Password=<User Password>

Ø  Local Service should have Full Control on website directory i.e. “C:\inetpub\wwwroot”.
Ø  Following providers must be added in Management service delegation rule: setAct, createApp, contentPath, iisApp.

We can use a blank rule and add these providers or following three rules from the templates:

1. Deploy Applications with content
2. Mark Folders as applications
3. Set Permissions for applications.
Ø  Identity Type should be “ProcessIdentity”
Ø  Path should be {userScope}

Read more: Getting started with IIS 7 - Amol Mehrotra

Posted via email from Jasper-Net

MSBuild Extension Pack

The MSBuild Extension Pack December 2010 release provides a collection of over 380 MSBuild tasks. A high level summary of what the tasks currently cover includes the following:

• System Items: Active Directory, Certificates, COM+, Console, Date and Time, Drives, Environment Variables, Event Logs, Files and Folders, FTP, GAC, Network, Performance Counters, Registry, Services, Sound
• Code: Assemblies, AsyncExec, CAB Files, Code Signing, DynamicExecute, File Detokenisation, GUID’s, Mathematics, Strings, Threads, Xml, Zip Files
• Applications: BizTalk 2006 / 2009, Email, IIS6, IIS7, MSBuild, SourceSafe, SQL Server 2005, SQL Server 2008, StyleCop, Twitter, Team Foundation Server, Visual Basic 6, Windows Virtual PC, WMI

Read more: Codeplex

Posted via email from .NET Info

HowTo: Open MSTest with MSBuild

According to the blogpost about „HowTo: build solutions with MSBuild“ I’m going to show you a little example about how to call MSTests.

Scenario
The structure is nearly the same like in this blogpost. As a little add-on I created a new test project:


I’ve added one more “RunTests” target to my BuildSolutions.target file where the MSBuild Script is included:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">

<PropertyGroup>

<OutDir>$(MSBuildStartupDirectory)\OutDir\</OutDir>

<SolutionProperties>

OutDir=$(OutDir);

Platform=Any CPU;

Configuration=Release

</SolutionProperties>

</PropertyGroup>
<ItemGroup>

<Solution Include="..\MsBuildSample.sln">

<Properties>

$(SolutionProperties)

</Properties>

</Solution>

</ItemGroup>
<Target Name="Build">

<MSBuild Projects="@(Solution)"/>

</Target>

<Target Name="RunTests">

<Exec Command='"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe" /testcontainer:"$(MSBuildStartupDirectory)\OutDir\MsBuildSample.WebApp.Tests.dll" /testcontainer:"$(MSBuildStartupDirectory)\OutDir\AnotherTestProject.dll"' />

</Target>

</Project>

Read more: Code-Inside Blog International

Posted via email from .NET Info

HowTo: MSDeploy & MSBuild

Big Picture from MSDeploy

We start with the big picture of MSDeploy. The aim is to build a Deployment Package to make the delivery of software easier. Therefore we have several providers which are used to, for example, pack the data bank or the main ASP.NET Files into one package. Now you are able to publish this package quit easy with MSDeploy. MSDeploy should be installed on the Server too.
At this point I recommend you the blogs of ScottGu and Vishal Joshi (feels like he is THE developer behind MSDeploy).

One of the main advantages of MSDeploy: it’s very easy to bring in new updates. For example you can use the developer-machine of Visual Studio or a Buildserver with a Buildscript.

Read more: Code-Inside Blog International

Posted via email from .NET Info

HowTo: build MSBuild Solutions

Those of you who are already experts in the usage of MSBuild will be just smiling about my Blogspot but for someone who hasn’t worked with MSBuild till today (like me) I thought this howto would be very helpful.
Introduction to MSBuild
At this point I won’t give you a great introduction into MSBuild. MSBuild is the basic for the development process of .NET Projects. There is another great Tutorial from Thorsten Hans. Please take a look on it if you would like to have a deeper few into the whole MSBuild problem.
Whats my problem
I had a specific problem for me. At our enterprise we use the TFS 2010 including the Teambuilds. Now I want to have a Buildscript on the client who is able to build every solutions local (we have a lot of – big project) and pass it to a folder. The TFS works quite similar and pass everything after the successful build into the droplocation. Thats what I want to build after.
Demoproject
I know my demo is very thin and includes just an ASP.NET MVC project with Unit Tests – unchanged standard:
Read more: Code-Inside Blog International

Posted via email from .NET Info

ILMerge – How to Merge Assemblies After A Build

The other day I mentioned I was working on an API to communicate with Sonic, an enterprise messaging system.  After getting the API to the point where I wanted to send it to some other developers I wanted to package everything up as on DLL.  ILMerge to the rescue!
Sonic provides their own DLLs that were ported from Java for .NET developers.  There are 7 DLLs you have to reference in order to communicate with Sonic.  Here’s how this can be done using ILMerge by simply modifying the project file using an after build target.
The following below does a few things.
It takes all of the assemblies that are outputted to the build directory and passes that to the ILMerge command.
Once they are merged the files are deleted.
<Target Name="AfterBuild">

<CreateItem Include="@(ReferenceCopyLocalPaths)" Condition="'%(Extension)'=='.dll'">

<Output TaskParameter="Include" ItemName="IlmergeAssemblies" />

</CreateItem>
<Exec Command="&amp;quot;$(MSBuildProjectPath)..\..\ThirdPartyAssemblies\Ilmerge\Ilmerge.exe&amp;quot; /allowDup /log /keyfile:$(AssemblyOriginatorKeyFile) /out:@(MainAssembly) &amp;quot;@(IntermediateAssembly)&amp;quot; @(IlmergeAssemblies->'&quot;%(FullPath)&quot;', ' ')" />
<Delete Files="@(ReferenceCopyLocalPaths->'$(OutDir)%(DestinationSubDirectory)%(Filename)%(Extension)')" />

</Target>
Read more: Words of Wisdom From The Elder

Posted via email from .NET Info

ImaginaryRealities MSBuild Extensions

Project Description
This project contains the source code for MSBuild extensions that were created by ImaginaryRealities for building our software products.
Read more: Codeplex

Posted via email from .NET Info

Create a Build File for a Visual Studio Solution - MsBuild Series

Why create a build file for a Visual Studio
Solution?
A build file automates the process of building, testing, analyzing, packaging, & deploying your project. Build files can be used to give you a single click solution to perform mundane tasks in a consistent way.
It saves you time by automating all the tedious steps necessary to prepare your project for testing or deploying. It reduces risk because you can confidently repeat the process, there's no change you will forgot to rename a file or change to release mode etc etc.
OK but How?
Creating a build file for the first time can be a little tricky so I have prepared a quick tutorial on creating a simple msbuild file for compiling your solution. Just follow the steps below and let me know if you have any issues.
1) Folder Structure
Once we start running builds of our project we need a place to store the results. We may also need extra tools for our build process and of course we need a place for our new build file.
Below is a the folder structure I will be using for this introduction. It allows us to keep all of the build files / folders out of our source tree.
Project Root:/
/Build – result of the build will be placed in here
/Source – all source code (& libraries) for the project
/Tools – collection of tools used for the build process
/build.bat – simple 'double click to build' ms dos batch file
/build.proj– our build file for msbuild, this is where we define the steps for our build process
2) Creating the Batch File
Create a new blank file called build.bat in the root directory of your project. This will be a simple ms dos batch file to kick off our build script. Simple copy the contents below into the batch file.
REM dont remove this line
"%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" /nologo build.proj  %*
Make sure you leave the first line intact, otherwise you may run into problems because of the encoding used to save the file. If you have issues with encoding then you may need to open the file using a specific encoding (850) see: http://msdn.microsoft.com/en-us/library/dxfdkfke(VS.80).aspx.
The batch file simply calls msbuild.exe and passes in our build.proj file. The %* argument passes any command line arguments supplied to the batch file into the msbuild.exe command. This allows us to specify a target at the command prompt like this: build /t:clean
4) Creating the Build File
Read more: Marks asp.net / mvc blog

Posted via email from .NET Info

Integrating sandcastle into build process to generate MSDN style documentation

A well documented code is always a good thing especially when it comes to maintaining it. I’d like to remind you guys a quote from Rick Osborne
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
In this article I will walk through how to integrate Sandcastle tool to generate MSDN style documentation for your code. Before we look at how to get sandcastle tool integrated into your build process, I’d like to remind couple of things.
If you are not adding XML documentation to your code, start getting into that habit , all public methods/properties and classes should have XML documentation. For more information on recommended tags please read http://msdn.microsoft.com/en-us/library/5ast78ax(v=VS.100).aspx
You should turn on XML documentation for all your source projects, you can do this by going into project properties and selecting the build option as shown in the picture below
Read more: Ram's Blog

Posted via email from .NET Info

SSIS MSBuild task now included in MSBuild Extension Pack

The information in this blog post may be of interest to anyone out there that is using Continuous Integration with msbuild in order to build/deploy a project that includes SSIS packages.
The MSBuild Extension Pack at http://msbuildextensionpack.codeplex.com/ now includes an MSBuild task that will build an SSIS project, the output from which is a .deploymentmanifest file that can be used in concert with the SSIS deployment utility.
Building a SSIS project using the SSIS MSBuild Task essentially has the same effect as right-clicking on a SSIS project and selecting Build with CreateDeploymentUtility=True (i.e. produces a .deploymentmanifest file):

Read more: SQL Blog.com

Posted via email from .NET Info

Mim: the build system you always wanted

The word mim means any of the following:

• an incorrect way of writing 1999 in roman numbers (as in "we gonna party like it's 1999"),
• the Madame Mim from the Disney movie Sword in the Stone,
• Swedish for "mime" meaning "imitating"
• a figure in Norse mythology renowned for his wisdom
• an acronym for "Mim Isn't Make"

   it's also the name of the build system I've been thinking and working of for a while. This post is about what Mim is now and what it can become. Text in red describes stuff that isn't implemented yet, text in yellow is things that are kind-of implemented, and text in black describes implemented features. First, I'll describe how Mim is different from other build systems and why it's better.
Problem
The problems with traditional build system are:

• make sure the dependencies are correct and built in the right order (think: make depend && make && make install),
• be sure of that every built file you see is up to date,
• hard understand how a software project is built (what are the artifacts? where are they stored? what are the dependencies?),
• hard to understand which variables a build have (e.g., make DEBUG=1)

Solution
   The solution to these problem is (of course) Mim. With Mim you clearly see all artifact the build system produces, how they are built, and when they need to be built. In fact, you can see the artifacts, e.g., by doing ls, before they are built. In other words, using your normal command line tools you can browse the project file tree to find the artifact you need (to run, to view, to copy, etc.) without building anything. Sounds like magic? Keep reading...
Read more: Programmatically Speaking

Posted via email from .NET Info

MSBuild Extension Pack August 2010 Release

The MSBuild Extension Pack August 2010 Release is  now available to download.
The August 2010 release contains

• version 3.5.7.0 for those using .Net 3.5
• version 4.0.1.0 for those using .Net 4.0

This release contains the following high level changes

• Numerous documentation improvements
• 13 new Task Actions
• New FTP Task
• New DNZip Task which removes the need for the J# Redistributable
• New SQL Logger (4.0.1.0)
• Improved support for VS 2010 and .Net 4.0 features.
• Various improvements to existing Tasks
• Various bug fixes

For full details of all changes please see the Changesets listed on CodePlex. We’re fast approaching 50 000 downloads. Thanks for all the support and suggestions that have made this release possible.
Read more: FreeToDev

Posted via email from .NET Info

MSBuild Hands-On

This site provides a Hands-On MSBuild experience. Try the Lab and feel free to provide feedback.
We are currently evaluating appropriate content for this site. Please check back soon for videos and more.
Read more: MSDN

Posted via email from .NET Info

MSBuild: Basics

I have spent a good deal of time with MSBuild scripts the past couple of years as I have worked on various projects. As I have attempted to make these scripts bend to my wishes I have gradually improved the sample MSBuild script I carry along to each new project. In this series I will cover various ways to use MSBuild and include some tips on what you can do to make your scripts work better for you. But first, what is MSBuild?
The MSBuild utility was introduced with .NET 2.0 and is available with the runtime even if Visual Studio is not installed. It allows for build automation of most Visual Studio project types. Previously, a utility called NAnt was used as a build tool for .NET 1.1 which is modeled after Ant, a tool to build Java projects. The introduction of MSBuild as an official utility was very welcome among the development community as it provides close integration with the existing project and solution files created by Visual Studio. This close integration cuts down on the amount of detail necessary for the build scripts.

In some ways MSBuild is quite similar to the NAnt and Ant predecessors, such that the scripts are XML files representing Targets of execution with various Tasks within those Targets. And between Targets a dependency tree can be created to ensure certain Targets are completed before the called Target. That is all quite similar to NAnt and Ant. However, the way properties and lists are defined is quite different.
Read more: Brennan’s Blog Basics, Item Group, Dependencies, Configuration, Web Deployments, Unit Test, Packaging

Posted via email from .NET Info