I'm calling MSTest like this:
<Target Name='UnitTests'>
<CallTarget Targets="BeforeUnitTests" />
<Exec Command='"$(VS90COMNTOOLS)..\IDE\mstest.exe" /testmetadata:$(SourceCodeRootFolder)ASA.File.Processing.vsmdi /testlist:buildtests' />
<CallTarget Targets="AfterUnitTests" />
</Target>
It's running, but whether it succeeds or fails, no errors are written to the MSBuild error file. I'm running MSBuild with these parms:
/fl /flp:v=detailed;logfile=Errors.txt;errorsonly
I have emails set up to email our team if there are errors in the Errors.txt file.
Unless the MSTest program itself fails, you won't get errors in the MSBuild logfile, at least from the test portion of your build stream.
One of the MSTest options is to publish the results to TFS; you should be able to use standard notification setup there to let your teammates know what happened. Or you could use the resultfile parameter in the MSTest call and parse/publish based on what you find in the file.
We use Codeplex project Trx2Html to publish the results to an internal website that everyone has access to.
Related
I need to build at the solution level using MSBuild since I have multiple configurations. I have a custom target in my web project that publishes the output. I can specify the web project as the target and it builds fine. But I need to publish the web application. Is there a way to build a project's custom target when building at the solution level?
I found this link, but I don't understand the solution. If someone could break that down a little, it would help a lot.
This is what my current PowerShell command-line looks like:
& "$env:windir\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" `
"..\..\Solution.sln" `
"/t:WebApplication:PublishToFileSystem" `
"/p:Configuration=$configuration;PublishDestination=$publishPath"
The :PublishToFileSystem causes it to fail, with this message:
error MSB4057: The target "PublishToFileSystem" does not exist in the project. [C:\Source\Solution.sln]
This is what my custom target in my .csproj file looks like:
<Target Name="PublishToFileSystem" DependsOnTargets="PipelinePreDeployCopyAllFilesToOneFolder">
<Error Condition="'$(PublishDestination)'==''" Text="The PublishDestination property must be set to the intended publishing destination." />
<MakeDir Condition="!Exists($(PublishDestination))" Directories="$(PublishDestination)" />
<ItemGroup>
<PublishFiles Include="$(_PackageTempDir)\**\*.*" />
</ItemGroup>
<Copy SourceFiles="#(PublishFiles)" DestinationFiles="#(PublishFiles->'$(PublishDestination)\%(RecursiveDir)%(Filename)%(Extension)')" SkipUnchangedFiles="True" />
</Target>
So, after some research, I found that creating a custom target is not the best way to publish a web application. Assuming you have just one web project in your solution, MS extended MSBuild to use publish profiles (the same ones used when you publish in Visual Studio). I was able to create a separate publish profile for each configuration (environment) and call the following command line:
& "$env:windir\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" `
"..\..\Solution.sln" `
"/p:DeployOnBuild=true" `
"/p:PublishProfile=$configuration"
I just had to make sure my publish profiles had the same name as my $configuration.
I have created a custom .proj file that builds my web site project's solution. It seems to all work correctly and it produces an output. However, when I put it on the server, I got an error about "/Default.aspx is not precompiled and cannot be requested". After some digging I discovered that indeed the precompiled aspx files were not precompiling. In the output from msbuild, I found a call to aspnet_compiler:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /WebApplication -p WebApplication\ -f -fixednames Output_PublishedWebsites\WebApplication\
When I run this command directly, it generates everything just fine.
How can I get my msbuild wrapper to perform this correctly?
My msbuild task looks like this:
<MSBuild Projects="$(SolutionFile)"
Properties="OutDir=$(OutputRoot);
Configuration=$(AspNetConfiguration)"
Targets="Build" />
I solved this by using the <AspNetCompiler /> task.
I am facing an issue with MSBuild I can't overcome it by myself. As a result I rely on community's wisdom.
The real situation I'm having troubles with
I have a soluiton file containing several projects with dependencies to other projects in same solution. I'd like to append a custom target to one of the project's csproj file and build it from the command line. It will allow me to make all the necessary output binaries for this project for further processing during the building of the custom target. But the main thing is that I can't figure out how to do it, googling doesn't help either.
Simplification
To make thing simplier I decided to make a new C# console project, add a simple custom target to the project's file and try to make it build. Still no success! Here what I've done so far:
Created a solution app with a default console project coreapp. This gaves me at least two files:
app.sln
coreapp\coreapp.csproj
Modified coreapp.csproj with addition of my custom target inside of the Project tag
<Target Name="SampleTarget">
<Message Text="This is a SampleTarget" />
</Target>
Run on the command line the following command
%windir%\Microsoft.NET\framework\v3.5\msbuild.exe app.sln /t:coreapp:SampleTarget
or even
%windir%\Microsoft.NET\framework\v3.5\msbuild.exe app.sln /t:coreapp.csproj:SampleTarget
Results
No luck, facing the error
MSB4057: The target "coreapp.csproj:SampleTarget" does not exist in the project.
I suspect that MSBuild thinks somehting fundamentally different from what I want it to think...
BEsides that, I also tried to set on the same command line the environment variable MSBuildEmitSolution=1 to force msbuild dump a temporary solution file it creates while processing the solution. In this file, indeed, no such target. However I guess it isn't the reason because I asked msbuild to build coreapp.proj where target SampleTarget really resides.
The question is how to build SampleTarget in this simplified scenario using solution file since potencially it can contain dependencies for the project containing this SampleTarget target?
I'd be greatful for any sort of help or firection for further investigation!
Instead of inserting a custom target in your project file, you could try creating a new standalone msbuild file, which would:
build the solution file (which builds projects)
defines your extra target
Call it app-custom-Debug.msbuild , for example.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WorkingFolder>$(MSBuildProjectDirectory)</WorkingFolder>
<Configuration>Debug</Configuration>
<SolutionFile>app.sln</SolutionFile>
</PropertyGroup>
<Target Name="Build" DependsOnTargets="Compile" />
<Target Name="Compile">
<Message Text="=== COMPILING $(Configuration) configuration ===" />
<MSBuild Projects="$(SolutionFile)"
Properties="Configuration=$(Configuration)" />
</Target>
<Target Name="SampleTarget">
<Message Text="This is a SampleTarget" />
</Target>
</Project>
Then you execute:
msbuild.exe app-custom-Debug.msbuild /t:SampleTarget
One option is to tie your SampleTarget to the standard Build targets via overriding the appropriate DependsOn property. In this case you could tell BeforeBuild that it DependsOn SampleTarget or you do the same thing with AfterBuild. This will ensure that MSBuild processes your target prior to the standard target indicated.
World's simplest task (see below) is not being executed after I publish my web application project. Any idea why?
<Target Name="AfterPublish">
<Copy SourceFiles="C:\A.txt" DestinationFiles="C:\B.txt" />
</Target>
Note: The following applies to VS2010 and publishing web-application projects with the "Web Deploy" publish method selected in the 'Build/Publish {projectname}' dialog.
Julien Hoarau's correct in that "Publish" is NOT the name of the msbuild target invoked in the above case; the actual target name is "MSDeployPublish".
Therefore, you have to define a "Target" element whose "AfterTarget" attribute's value is set to "MSDeployPublish" - the "Name" attribute's value does not matter (as long as it's unique among target names).
Here's how to do it:
Open the project file (e.g. *.csproj) in a text/XML editor and, just before the closing </Project> tag, add a <Target Name="CustomPostPublishAction" AfterTargets="MSDeployPublish"> element; pick a name of your choice for "CustomPostPublishAction".
Add a so-called Task child element that performs the desired action; for instance, to add a command to be passed to cmd.exe, use an <Exec Command="..." /> element.
Example:
<Target Name="CustomPostPublishActions" AfterTargets="MSDeployPublish" >
<Exec Command="echo Post-PUBLISH event: Active configuration is: $(ConfigurationName)" />
</Target>
Note:
In command strings, use XML entity(?) references in place of characters that would break XML parsing, e.g. ">" in place of "<".
For documentation of the <Target> element in general, see http://msdn.microsoft.com/en-us/library/t50z2hka.aspx
Task-elements reference here: http://msdn.microsoft.com/en-us/library/7z253716.aspx
In general, if you need to determine the name of the msbuild.exe target that is actually invoked by Visual Studio 2010, do the following:
Go to Tools/Options..., Project and Solutions/Build and Run, select 'Detailed' (or, for even more information, 'Diagnostic') from the dropdown list labeled 'MSBuild project build output verbosity.
After running the build/publish action, e.g. Build/Publish, examine the Output window for the last occurrence of the string "Done building target" to determine the top-level target that was invoked.
Visual Studio 2013. Publish Web application to file system.
<Target Name="Moose" AfterTargets="GatherAllFilesToPublish" >
<Message Importance="high" Text="***Moooooooooooooooose***$(WPPAllFilesInSingleFolder)***$(TargetDir)" />
</Target>
Note: Make sure that build logging is set to at least to Detailed. Look for it under Tools -> Options -> Projects and Solutinos -> Build and Run -> MSBuild output verbosity. Diagnostic is also fine if you want to investigate which build target was last run before actual publish.
This seems to work in Visual Studio 2019
<Target Name="MyCustomTarget" AfterTargets="Publish">
<Copy SourceFiles="C:\A.txt" DestinationFiles="C:\B.txt" />
</Target>
You must define override the target at the end of your file, after <Import ... />
Launch MSBuild with detailed verbosity to see why your target is ignored :
msbuild project.csproj /t:Target_to_Launch /v:d
AfterPublish is called after Publish target, but Publish is not the target called when you publish a web application. Publish is the target for publishing ClickOnce application.
You'll have to find the target used when you call Publish in Visual Studio, it could be Package, WebPublish...
I'm a little lazy right now to figure out the mess of targets to find the right one for a file-based publish (which you might be interested in). What you can do in the meantime is defining an AfterBuild target in the *.pubxml file.
<Target Name="AfterBuild">
...
I recommend also turning off the property "DeleteExistingFiles" because if you copy files into the directories being published, it does a clean somewhere during the publishing process.
<DeleteExistingFiles>False</DeleteExistingFiles>
To an earlier question of mine, invovling VBC and NAnt with WinForms, I have since come up with a better way of stating this.
Within vbproj file, you have the following:
<ItemGroup>
<None Include="My Project\Settings.settings">
<Generator>SettingsSingleFileGenerator</Generator>
<CustomToolNamespace>My</CustomToolNamespace>
<LastGenOutput>Settings.Designer.vb</LastGenOutput>
</None>
</ItemGroup>
<ItemGroup>
<Content Include="My Project\Application.myapp">
<Generator>MyApplicationCodeGenerator</Generator>
<LastGenOutput>Application.Designer.vb</LastGenOutput>
</Content>
</ItemGroup>
When one runs build from within Visual Studio (Debug Verbosity set to Normal), one of the lines produces is:
Target CoreCompile:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Vbc.exe ...
Which includes all of the settings required for vbc.exe to run. However, taking that string from Visual Studio, and running it directly on the command line yields:
... My Project\Settings.Designer.vb(67) : error BC30002: Type 'My.MySettings' is not defined.
Friend ReadOnly Property Settings() As Global.My.MySettings
...\My Project\Settings.Designer.vb(69) : error BC30456: 'My' is not a member of '<Default>'.
Return Global.My.MySettings.Default
How does one get the above Generators to run from a command line, or is there a call somewhere that will generate the correct temp files that are needed for vbc.exe to run the command string correctly?
The problem with looking at the build string within visual studio is that it's not actually calling vbc.exe to build from visual studio. All builds in visual studio happen with the in-memory compiler instead of the command line compiler (true for C# as well).
The command that looks like vbc.exe ... is a generated string that isn't actually executed. If you want to find out the correct string to build your project run the following code from a visual studio command prompt.
msbuild /v:diag myproject.vbproj
This will produce an msbuild log file (it will be quite long so I suggest piping to a file). Once the build is completed search for vbc.exe within that file. It will have the actual command line needed to build your project.
I spent a while working on this today. I'd like to know a proper answer as to how to get the vbc compiler to work properly in regard to the "My" namespace, but I managed to get my NAnt script working using NAnt contrib (http://nantcontrib.sourceforge.net/).
NAnt contrib allows you to build using the .NET msbuild, which at least allowed me to set up automated builds, notifications, etc. It does not give quite the granular control I would like, but it serves its purpose.
The reference on this task is:
http://nantcontrib.sourceforge.net/release/latest/help/tasks/msbuild.html
And the pertinent snippet from my build script:
<target name="build" depends="clean">
<msbuild project="ProjectName.vbproj" />
</target>
I've used NAnt quite a bit for CS applications, but this is the first for a VB.NET application.