I've recently introduced NUnit to a Visual Studio C# project. The project folder structure looks like
- project root
-- applications (rich client interface, web interface, small tools)
-- components (business logic)
-- vendor (3rd party components)
-- tests (Nunit tests)
For each Visual Studio project "MyProject" under applications or components there is a corresponding project under tests named "MyProject.Test". When I introduced the NUnit test, I put the following in each .Test.csproj file:
<Target Name="AfterBuild">
<CreateItem Include="$(TargetPath)">
<Output TaskParameter="Include" ItemName="MyProjectTests" />
</CreateItem>
<!-- Create folder for test results -->
<MakeDir Directories="$(OutDir)\TestResults" />
<!-- Run tests-->
<NUnit Assemblies="#(MyProjectTests)" ToolPath="..\vendor\NUnit\bin" OutputXmlFile=".\TestResults\MyProject.Test.Results.xml" WorkingDirectory="$(OutDir)" />
<!-- Create HTML report -->
<Xslt Inputs="$(OutDir)\TestResults\MyProject.Test.Results.xml" Xsl="$(MSBuildCommunityTasksPath)\NUnitReport.xsl" RootTag="Root" Output="$(OutDir)\TestResults\MyProject.Test.Results.html" />
</Target>
This works fine, both when building solutions from within Visual Studio as well as on a build server with the MSBuild CLI.
The remaining inconvenience of that approach is that it leaves me with the test reports in a TestResults folder in each test projects output folder, but with nothing in my solution's main output folder. So, my question is:
What is the preferred way of collecting the resulting NUnit html reports in the solution's/startup project's output folder? What MSBuild instructions should I place in which .csproj file? I'm just getting started with MSBuild and I can't figure out the best practice...
It has to work both in Visual Studio and with the MSBuild CLI, but that shouldn't be a problem, I guess.
Thanks
If you have a build server, one good approach is to setup a site with a virtual path configured to your test folder. Then any person on your company can browse something like http://build.companydomain.local/yourapp/nunitreports/, hosted on the build server's IIS (in case your build server have one).
I'm doing this with my coverage reports. Any person can browse it at any moment. I hope it helps!
Related
I'm trying to add some simple MSBuild tasks to a Visual Studio project (VS 2012 Express) - specifically, to create a subdirectory then copy some files to a subdirectory of the output directory ready for packaging.
I see that VS supports custom build steps, which are command-line invocations. However, since VS is based on MSBuild it should be possible to add these directly as MSBuild tasks like the Copy Task in the AfterBuild pre-defined target.
What I can't find is any way to actually add such tasks within the framework of Visual Studio. The documentation only talks about it from an MSBuild perspective, not how it works within Visual Studio's UI. It also doesn't seem to discuss the properties that refer to build output etc there; presumably they're just those used by msbuild its self.
Is there support for MSBuild task management in Visual Studio's UI and it's just crippled out of my Express edition? Or do I have to go hack the project file XML to add MSBuild tasks? Is that supported and the way it's supposed to be done?
I'm used to working with Eclipse and Ant or Maven, where all this is supported within the IDE, though of course you can hack the XML directly. Finding no UI at all for MSBuild task management in Visual Studio is quite confusing. Am I missing the obvious or crippled by using the freebie edition?
For C++ projects, you can use the property
<CppCleanDependsOn>DeleteOutputs;$(CppCleanDependsOn)</CppCleanDependsOn>
instead of defining the BeforeClean target like you did.
From what I read, CallTarget is to be avoided. In your example, you should use DependsOnTargets to do that, as you see in many dummy targets in the MS supplied files. The analogous mechanism of a function where a target just "calls" other targets is done with DependsOnTargets. The flow is not really the same as procedural programming.
Intellisense: I never use it. Is that true for conditional AdditionalIncludeDirectories in the props file only? Go ahead and edit the entry in the proj file where the IDE put it, if you edit the property in the IDE with just one configuration chosen.
(After a bunch more reading I found out how this works):
Visual Studio doesn't seem to expose advanced MSBuild project editing, even though modern vcxproj files are just MSBuild project files with a bunch of extra labeled properties and other entries for Visual Studio IDE specifics. So you have to hack the project XML.
To make it cleaner, only add one line to your actual vcxproj file - an include of a .targets file that contains the rest of your build customisations. e.g, just before the end of the project file, insert:
<Import Project="pg_sysdatetime.targets" />
</Build>
Now create your .targets file with the same structure as any other MSBuild project. Here's mine from the project I've been working on:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- MSBuild extension targets for Visual Studio build -->
<PropertyGroup>
<DistDir>pg_sysdatetime_pg$(PGMAJORVERSION)-$(Configuration)-$(Platform)</DistDir>
</PropertyGroup>
<ItemGroup>
<DocFiles Include="README.md;LICENSE"/>
<ExtensionSourceFiles Include="pg_sysdatetime--1.0.sql;pg_sysdatetime.control"/>
<ExtensionDll Include="$(TargetDir)\pg_sysdatetime.dll"/>
</ItemGroup>
<Target Name="CopyOutputs">
<Message Text="Copying build product to $(DistDir)" Importance="high" />
<Copy
SourceFiles="#(DocFiles)"
DestinationFolder="$(DistDir)"
/>
<Copy
SourceFiles="#(ExtensionDll)"
DestinationFolder="$(DistDir)\lib"
/>
<Copy
SourceFiles="#(ExtensionSourceFiles)"
DestinationFolder="$(DistDir)\share\extension"
/>
</Target>
<Target Name="DeleteOutputs">
<Message Text="Deleting $(DistDir)" Importance="normal" />
<Delete Files="$(DistDir)"/>
</Target>
<!-- Attach to Visual Studio build hooks -->
<Target Name="BeforeClean">
<CallTarget Targets="DeleteOutputs"/>
</Target>
<Target Name="AfterBuild">
<CallTarget Targets="CopyOutputs"/>
</Target>
</Project>
This can contain whatver MSBuild tasks you want, grouped into targets. It can also have property groups, item groups, and whatever else MSBuild supports.
To integrate into Visual Studio you add specially named targets that invoke what you want. Here you can see I've defined the BeforeClean and AfterBuild targets. You can get the supported targets from the VS integration docs.
Now, when I build or rebuild, a new directory containing the product DLL and a bunch of static files is automatically created, ready to zip up. If I wanted I could add the Nuget package for MSBuild Community Extensions and use the Zip task to bundle the whole thing into a zip file at the end too.
BTW, while you can define properties in your .targets files it's better to define them in property sheets instead. That way they're visible in the UI.
I'm using VS2010 Pro, and it doesn't expose the AfterBuild target, at least in C++ projects which is what I'm doing. As you see, it does have the "Events", which according to what I've read are for backward compatibility with converted projects from VSBuild. I agree, a MSBuild task rather than a command script is the way to go.
Forget the UI. It's made to support free editing of the XML files, and continue using the UI too as it respects what you had in there and uses labels for its own stuff so it can find it to update it.
But to keep it neat, you could use a property page; a stand-alone XML file with *.props name, and put what you want in it. Then add that props file to the projects using the UI. You won't hand-edit the project file that the UI is maintaining, and it won't touch the props file unless you go through the property manager view and open it explicitly.
Oh, I also recall seeing additional standard targets something like Package and Publish. Maybe those are not used on your project type, but you could use those entry points anyway.
In the team I'm working in we have a big product with many WCF web services and some web sites which use the services. We are just about to upgrade to VS 2010 and I'm looking at if we should start using the new config transform functions in VS 2010.
We have several different environments which need different web.configs (database connection strings, WCF addresses and so on). Often when debugging something high up such as the web frontend it is useful to configure it to directly connect with the TEST or QA backend / databases. On each developer's local machine the IIS is configured directly to the source folder of each WCF/web project, and when running locally it is a simple matter of Ctrl-Shift-B or F5 to debug something.
One would think that it would be possible to build/F5 with TEST or QA as configuration mode and get the TEST/QA config, but I don't see how. Is it not supported, or maybe we need to change how we work with things?
Our other option is to instead use a simple replace-script as a prebuild event that creates the web.config from a template and a key-file depending on configuration mode. With this method you would get TEST config if you compile in TEST and so on but it feels a bit bad to roll our own solution when there is a function built into Visual Studio.
You can achieve the effect you're looking for by using the BeforeBuild and AfterBuild targets available in the .csproj file. The VS.NET IDE will execute these targets when doing a Build or a Rebuild, so you can use them to execute the web.config transforms. Since you'll need to do a web.config transform and then overwrite the actual web.config file, you'll need to rely on a new file called web.default.config to store the base web.config data.
I tried this out in a test project, here were the changes I made to the .csproj file:
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<ProjectExtensions>
...
</ProjectExtensions>
<Target Name="BeforeBuild">
<Copy SourceFiles="$(ProjectDir)web.default.config" DestinationFiles="$(ProjectDir)web.config" />
</Target>
<Target Name="AfterBuild" Condition="$(FirstRun) != 'false'">
<MSBuild Projects="$(MSBuildProjectFile)" Targets="TransformWebConfig" Properties="FirstRun=false;" />
<Sleep Milliseconds="2000" />
<Copy SourceFiles="$(ProjectDir)obj\$(ConfigurationName)\TransformWebConfig\transformed\web.config"
DestinationFiles="$(ProjectDir)web.config" />
</Target>
I had to manually add these to the .csproj file (I used Notepad++). As far as I can tell there is no way to add these instructions through the VS.NET IDE. You need to supply the conditional on the AfterBuild to keep from having a circular reference, as the call to MSBuild will rerun the build to generate the web.config transform.
Basically what we're doing is copying the web.default.config file (our base template) over the existing web.config before we start to build, and then we use MSBuild to generate a web.config for whatever configuration we're building. After the transform is complete, we use a Copy task to take the transformed file and copy it over to the web.config file in the web root. One issue I occasionally ran into was a file in use error when trying to overwrite the web.config after the transform was complete. Adding a Sleep task (from MSBuildCommunityTasks) after the MSBuild task took care of that issue.
I only tested this approach using the built in ASP.NET server, not IIS, so YMMV but I feel like this is a workable solution.
The FirstRun idea came from this post.
I have configured Specflow to target the MsTest framework (instead of NUnit) by specifying it like this in the app.config of my 'specs' class library:
<configSections>
<section name="specFlow"
type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
</configSections>
<specFlow>
<unitTestProvider name="MsTest.2010" />
</specFlow>
So once it's in place, I can see that my test fixtures are produced correctly by the Specflow custom tool, with correct TestClassAttribute() and methods, etc:
[System.CodeDom.Compiler.GeneratedCodeAttribute("TechTalk.SpecFlow", "1.3.3.0")]
[System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute()]
...
The specs class builds, but now I cannot run the tests using the Test --> Run --> All Tests in Solution inside Visual Studio 2010 on my vista 64 box. Why doesn't VS recognize these as valid tests to run?
As per Dror Helper and Alex Duggleby you'll want to add the following line to your .csproj file:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Add it after the FileAlignment element, and reload the project. It should now be an MS Test project and you get the MS Test functionality in the context of this project. The Guids mean:
{3AC096D0-A1C2-E12C-1390-A8335801FDAB} - Test Project
{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} - C# Class Library
I had to recreate the project as a Test Project and not merely a Class Library -- because I had started development with NUnit and SpecFlow, I had created a vanilla class library to hold my specs that had the NUnit attributes decorated. I thought I could simply change the app.config of this existing project to point at the mstest framework and stop using NUnit, but VS2010 never recognized the tests, despite the correct creation of the stubs by specflow's custom tool.
So...I added a new Test Project to my solution, moved all of my spec code to that new project, then recompiled, and viola, VS2010 recognizes the tests. I'm sure there is a GUID it is looking for in the XML of the .csproj file or something that tells it to wire up the testing framework, but I didn't dig that far.
Hope this helps someone.
To change your class library project template into a test project, modify the .csproj and add the following line:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
to the first property group element:
<PropertyGroup>
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
I am trying to write unit tests for my transformations, so I am running:
msbuild migrated-project.csproj /p:Configuration=Release /T:TransformWebConfig.
This works for a new project I create in VS2010, but doesn't in this project. I'm assuming it's because it was originally a 2008 project. I know this is supposed to run in a webplatformbuild whatever, but what I'm trying to do, is just run the transform, so I can grab the transformed web.config, and run some unit tests to make sure the right values exist.
I don't see TransformWebConfig referenced as a target in either project, so I'm not sure what I'm looking for.
TransformWebConfig is referenced through Microsoft.WebApplication.targets, which references Microsoft.Web.Publishing.targets which contains the TransformWebConfig target you're after.
I don't know what's the problem with your project without having a look at your project file. Do you mind to attach it?
Might be worth to check whether the project references the version 10 of Visual Studio WebApplication target:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />)
instead of:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
I'm looking to extend some post build tasks to include the checking out and then checking in of a DLL. We are using TFS and I know there are command line tools to do this. What I don't know how to do is to integrate these into my existing post build tasks. Right now my post build tasks are simple and are managed in Visual Studio through the project properties. Eventually I want to break out my custom build tasks into external files and call them in, but that is the subject of another question ;)
Without resorting to custom Build tasks you could try to use the Team Foundation Source Control Command-Line tool (tf.exe).
The example below shows how to use tf.exe to check out a file from TFS.
<PropertyGroup>
<TfCommand>
"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\tf.exe"
</TfCommand>
</PropertyGroup>
<Target Name="AfterCompile">
<Exec Command="$(TfCommand) get /force /noprompt "$(SolutionRoot)\sources\example.cs""
ContinueOnError="true" />
<Exec Command="$(TfCommand) checkout "$(SolutionRoot)\sources\example.cs""
ContinueOnError="true"/>
</Target>
Include this in your own MSBuild project file.
This example doesn't do anything useful and you need to change it to match your environment, but maybe it gives you a start.
I got this example from tfsbuild.com.
You could use the Team Foundation Server client API. TeamFoundationServer is the base class that should allow you to connect to a server, list and manipulate TFS projects.
Msbuildtasks has some extensions for msbuild with sourcecode (its opensource). You could use this to create your own checkin/checkout functionality. (in combination with what Darin suggests)
http://msbuildtasks.tigris.org/
Take a look at the SDC Tasks Library on CodePlex. It's a set of custom MSBuild tasks that includes Checkin and Checkout tasks (see the Microsoft.Sdc.Tasks.SourceTfs namespace in the accompanying documentation). You can incorporate these tasks in the "AfterBuild" target in your project file.
<SourceTfs.Checkout Path="Path" TfsVersion="tfsVersion"
WorkingDirectory="workingDirectory"/>
<SourceTfs.Checkin Path="Path" Comments="Comments" TfsVersion="tfsVersion"
WorkingDirectory="workingDirectory" Override="overrideText"/>
You would set TfsVersion to "2005" or "2008" as appropriate.
Our team has several small projects which output DLL's used by several other projects. Part of our release is to publish these DLL's. I use the AfterDropBuild target for this. Hopefully the comments in my build script snippet are clear enough to show what I am doing.
<!-- Get a reference to the new release address finalizer DLL and the existing published address finalizer DLL -->
<PropertyGroup>
<ReleaseDLL>$(DropLocation)\$(BuildNumber)\Release\Address_Finalizer.dll</ReleaseDLL>
<PublishedFolder>$(SolutionRoot)\3rd Party\bin\PG File Import</PublishedFolder>
<PublishedDLL>$(PublishedFolder)\Address_Finalizer.dll</PublishedDLL>
</PropertyGroup>
<!-- Check out the published DLL -->
<Exec WorkingDirectory="$(SolutionRoot)" Command='$(TfCommand) checkout /lock:checkout "$(PublishedDLL)"'/>
<!-- Copy release to published -->
<Copy SourceFiles="$(ReleaseDLL)" DestinationFolder="$(PublishedFolder)"/>
<!-- Check in the published DLL -->
<Exec WorkingDirectory="$(SolutionRoot)" Command='$(TfCommand) checkin /override:Automated /noprompt /comment:"$(VersionComment)" "$(PublishedDLL)"'/>