Wrong version of aspnetcompiler when using msbuild 4.0 - msbuild

I'm trying to use the AspNetCompiler task within a custom msbuild file to precompile an asp .net 4.0 website. However, when i run:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe custom.msbuild /t:PrecompileWeb
it uses the v2.0.50727 aspnet_compiler. Is there a way to force it to use the v4.0.30319 aspnet_compiler? The reason I am asking is because I am getting this error:
ASPCONFIG: Unrecognized configuration section system.web.extensions.
However, if I run:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -p .\My.Web.Site -f .\.PRECOMPILATION -v /
It runs fine which makes sense because I am using system.web.extensions in the web.config and the 2.0 aspnet_compiler doesn't know what that is.

ToolPath works for the AspNetCompiler task, but the right thing to do is just set the ToolsVersion="4.0" attribute on your Project element- this will cause all built-in tools to use the correct version and doesn't require the hardcoding of paths.

Well I happened to be searching around some more and found the answer to my own question here:
http://blogs.msdn.com/b/webdevtools/archive/2010/05/14/the-aspnet-compiler-build-task-in-visual-studio-2010-asp-net-mvc-2-projects.aspx
What I ended up using was the ToolPath property for the AspNetCompiler task like so:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="PrecompileWeb">
<AspNetCompiler
VirtualPath="/MyWebSite"
PhysicalPath="c:\inetpub\wwwroot\MyWebSite\"
TargetPath="c:\precompiledweb\MyWebSite\"
Force="true"
Debug="true"
ToolPath="C:\Windows\Microsoft.NET\Framework\v4.0.30319\"
/>
</Target>
</Project>

Related

.NET Core console application is not creating an EXE file

I'm trying to publish a .NET Core console application following this tutorial, but when I publish, I don't get an executable file in the PublishOutput folder (I get a DLL file). I've also read this article.
My project file looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
</Project>
It seems pretty easy and straightforward, but what am I doing wrong?
Yeah, this is a weird one. I am still trying to work through it. I did find there seems to be a delay in getting the functionality from the CLI to Visual Studio 2017: This Stack Overflow article talks about that.
Also, there is ongoing confusion around exactly what Output type means since it is not what we all think. This GitHub issue talks about it.
I tried this on the Hello, World! template that Visual Studio provides. Change your .csproj file to the following:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<!--<OutputType>Exe</OutputType>-->
<TargetFramework>netcoreapp1.1</TargetFramework>
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
</PropertyGroup>
</Project>
I don't think the OutputType matters more than the RuntimeIdentifiers property.
Then using the console, run dotnet restore followed by dotnet publish -c release -r win10-x64
This should generate an EXE file under \bin\Release\netcoreapp1.1\win10-x64\publish
View this article from the same person in your first link.

Full list of /P MSDeploy arguments for MSBuild from TeamCity

I currently use the MSBuild runner in TeamCity for continuous integration on my local server and this works very well. However, I'm having trouble finding a full list of supported command line switches for MSDeploy in the format that TeamCity expects them.
In my 'Parameters' section at the moment I using the following switches:
/P:Configuration=OnCommit
/P:DeployOnBuild=True
/P:DeployTarget=MSDeployPublish
/P:MsDeployServiceUrl=https://CIServer:8172/MsDeploy.axd
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True
/P:UserName=Kaine
/P:Password=**********
/P:DeployIISAppPath="OnCommit/MySite"
/P:SkipExtraFilesOnServer=True
/P:DeployAsIisApp=True
All of these seem to work fine and the MSDeploy works as expected.
The trouble comes when I want to add additional parameters.
I've looked up MSBuild parameters and the MSDeploy documentation and I only seem to find command line parameters like these:
msbuild SlnFolders.sln /t:NotInSolutionfolder:Rebuild;NewFolder\InSolutionFolder:Clean
http://msdn.microsoft.com/en-us/library/ms164311.aspx
It seems that these references for command line arguments don't correspond with the /P: format - for example CreatePackageOnPublish and DeployIISAppPath aren't recognised command line parameters, but they work fine in the TeamCity build process.
Where can I find a full documented list of MSDeploy arguments in the format
/P:Param=Value
Additional info:
There's a list of parameters here:
http://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.build.workflow.activities.msbuild_properties.aspx
However this is not a complete list - for example, this list doesn't include DeployAsIisApp or SkipExtraFilesOnServer, which are both parameters that work from the Team City Build.
Also this related question (possibly duplicate): Valid Parameters for MSDeploy via MSBuild which contains some arguments - but still not a definitive list.
Firstly, the short answer is you can't find the complete list. MSBuild does not have a complete list of parameters you can chose from since you can send any parameter you like. It is a means of communication between the caller of MSBuild and the author of the MSBuild build script (a vs sln or csproj file for instance).
If the build script use the parameter it is used otherwise it is ignored.
So this is a valid call to msbuild:
msbuild /p:<anything>=<anything>
Secondly, you shouldn't send parameters to msbuild from teamcity using the /p: command options. Instead, set configuration or system properties in your teamcity build configuration. They will be passed to msbuild automatically as parameters.
Here are the parameters used by Visual Studio Team Services when creating an ASP.NET (Preview) build definition:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactstagingdirectory)\\"
One may also extrapolate from the <PropertyGroup /> blocks defined in these examples:
https://msdn.microsoft.com/en-us/library/ff398069(v=vs.110).aspx
From this example:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>Package</WebPublishMethod>
<LaunchASiteUrlAfterPublish>False</LaunchASiteUrlAfterPublish>
<SiteUrlToLaunchAfterPublish />
<MSDeployServiceURL />
<DeployIisAppPath />
<RemoteSitePhysicalPath />
<AllowUntrustedCertificate>False</AllowUntrustedCertificate>
<SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
<DeployAsIisApp>True</DeployAsIisApp>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
<UserName />
<SavePWD>True</SavePWD>
<PublishDatabaseSettings>
<!— this section omitted to keep the example short -->
</PublishDatabaseSettings>
</PropertyGroup>
</Project>
You could derive the following list:
WebPublishMethod
LaunchASiteUrlAfterPublish
SiteUrlToLaunchAfterPublish
MSDeployServiceURL
DeployIisAppPath
RemoteSitePhysicalPath
AllowUntrustedCertificate
SkipExtraFilesOnServer
DeployAsIisApp
MSDeployPublishMethod
UserName
SavePWD
PublishDatabaseSettings

CCnet send a value to App.config through MSBuild

Okay guys i am new here so i need a little help.I made automation test in c# for Nunit and i use it for CruiseControl
the CCnet.config:
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
<projectFile>ClassParseMicroData.sln</projectFile>
<buildArgs> /t:Build </buildArgs>
<targets>Build</targets>
<timeout>600</timeout>
<logger>C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<nunit>
<path>C:\Program Files (x86)\NUnit 2.6.2\bin\nunit-console.exe</path>
<assemblies>
<assembly>D:\SeleniumProject\microdata-csharp\test-class\ClassParseMicroData\ClassParseMicroData\bin\Debug\ClassParseMicroData.dll</assembly>
</assemblies>
<timeout>180000</timeout>
</nunit>
I want to send to MSbuild property for App.config from my test, something like this <buildArgs> /t:Build /p:link=test </buildArgs> it will be used in test, the problem is i don't know how to write App.config correctly to send this value. In test i will use like that ConfigurationManager.AppSettings["link"];
You might have to rewrite the ccnet.config to call a custom MSBuild script. In the custom MSBuild script you can use MSBuild Community Task using the XMLQuery or XMLUpdate task to get the value from the app.config file. Once the value from the app.config is acquired, it can then be passed in the call of the MSBuild to compile the solution file.
For more info on creating custom MSBuild scripts, the book Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build is a good guide. Alternatively you can use MSDN MSBuild reference.

Overriding MSBuildExtensionsPath in the MSBuild task is flaky

This is already cross-posted at MS Connect:
https://connect.microsoft.com/VisualStudio/feedback/details/560451
I am attempting to override the property $(MSBuildExtensionsPath) when building a solution containing a C# web application project via msbuild. I am doing this because a web application csproj file imports the file "$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets". This file is installed by Visual Studio to the standard $(MSBuildExtensionsPath) location (C:\Program Files\MSBuild). I would like to eliminate the dependency on this file being installed on the machine (I would like to keep my build servers as "clean" as possible). In order to do this, I would like to include the Microsoft.WebApplication.targets in source control with my project, and then override $(MSBuildExtensionsPath) so that the csproj will import this included version of Microsoft.WebApplication.targets. This approach allows me to remove the dependency without requiring me to manually modify the web application csproj file.
This scheme works fine when I build my solution file from the command line, supplying the custom value of $(MSBuildExtensionsPath) at the command line to msbuild via the /p flag. However, if I attempt to build the solution using the MSBuild task in a custom msbuild project file (overriding MSBuildExtensionsPath using the "Properties" attribute), it fails because the web app csproj file is attempting to import the Microsoft.WebApplication.targets from the "standard" Microsoft.WebApplication.targets location (C:\Program Files\MSBuild). Notably, if I run msbuild using the "Exec" task in my custom project file, it works. Even more notably, the FIRST time I run the build using the "MSBuild" task AFTER I have run the build using the "EXEC" task (or directly from the command line), the build works.
Has anyone seen behavior like this before? Am I crazy? Is anyone aware of the root cause of this problem, a possible workaround, or whether this is a legitimate bug in MSBuild?
Steps to Reproduce:
1) Create a new empty solution in MSVS 2008 (Fake.sln)
2) Add a new C# web application to the solution (WebApplication1.csproj)
3) Close MSVS
4) Copy the contents of "C:\Program Files\MSBuild\" to a directory called "MSBuildExtensions" in the directory containing your solution.
5) rename the directory "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications" so that WebApplication1.csproj will not be able to import Microsoft.WebApplication.targets from that location.
6) Create a custom MSBuild project file called "TestBuild.proj" in the same directory as the solution. It should have the following content:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="BuildMSBuild">
<PropertyGroup>
<MSBuildExtensionsPath>$(MSBuildProjectDirectory)\MSBuildExtensions\</MSBuildExtensionsPath>
<BuildThis>Fake.sln</BuildThis>
</PropertyGroup>
<Target Name="BuildMSBuild">
<MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);" Targets="Clean" />
<MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);"/>
</Target>
</Project>
7) execute "msbuild TestBuild.proj" from a MSVS command prompt (note: the build may succeed the first time, but will fail if you run more than once)
Did you try setting the environment variable MSBuildExtensionPath in the CMD prompt and then running your build?
For example:
C:\> SET MSBuildExtensionsPath=C:\My\MSBuild\Extensons
Then on this project file:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text='MSBuildExtensionsPath="$(MSBuildExtensionsPath)"' />
</Target>
</Project>
you will get the following output:
c:\Users\chuckeng\Desktop\ConsoleApplication1>"C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe" my.proj
Microsoft (R) Build Engine Version 3.5.30729.4926
[Microsoft .NET Framework, Version 2.0.50727.4927]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 6/25/2010 1:04:05 PM.
Project "c:\my.proj" on node 0 (default targets).
MSBuildExtensionsPath="C:\My\MSBuild\Extensons"
Done Building Project "c:\my.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.03
This works from v4.0 as well. Although, support is generally better in v4.0 for things like this. And, v4.0 is 100% backward compatible (bugs not withstanding). So, you can build your v3.5 and prior projects with v4.0. Just select ToolsVersion 3.5.
msbuild my.proj /tv:3.5
Hope this helps...
Chuck England
Visual Studio
Program Manager - MSBuild
This is a bug in MSBuild 3.5 but it is fixed in MSBuild 4.
If you can, switch to MSBuild 4 (you still can compile your 3.5 projects), otherwise you'll have to override the property in the project file.
It works fine if you override MSBuildExtensionsPath directly in the web app .csproj file.
<PropertyGroup>
<MSBuildExtensionsPath>C:\Users\madgnome\Desktop\msbuild</MSBuildExtensionsPath>
<!-- It works too with relative path -->
<!--<MSBuildExtensionsPath>..\msbuild</MSBuildExtensionsPath>-->
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
Don't know if this might help anyone in the future, but I was able to use the following at the top of my file and it works as I would expect in both 32 and 64 bit build environments.
<PropertyGroup>
<MSBuildExtensionsPath Condition=" '$(MSBuildExtensionsPath64)' != '' ">$(MSBuildExtensionsPath64)</MSBuildExtensionsPath>
</PropertyGroup>
<Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/>

How to resolve "Only one project can be specified" error from <msbuild> task in CruiseControl.NET

I'm trying to use the task in CruiseControl.NET version 1.3.0.2918 with a rather straight forward :
<project name="AppBuilder 1.0 (Debug)">
<workingDirectory>c:\depot\AppBuilder\1.0\</workingDirectory>
<triggers/>
<tasks>
<msbuild/>
</tasks>
</project>
However, when the project is run it fails with this information in the build log:
MSBUILD : error MSB1008: Only one
project can be specified. Switch: 1.0
For switch syntax, type "MSBuild
/help"
When I look at the ccnet.log file I find this:
Starting process [C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe] in working
directory [c:\depot\AppBuilder\1.0] with arguments [/nologo "/p:CCNetArtifactDirectory=C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts;CCNetBuildCondition=ForceBuild;CCNetBuildDate=2009-01-22;CCNetBuildTime=09:25:55;CCNetIntegrationStatus=Unknown;CCNetLabel=3;
CCNetLastIntegrationStatus=Failure;CCNetNumericLabel=3;CCNetProject=AppBuilder 1.0 (Debug);CCNetProjectUrl=http://CISERVER01/ccnet;CCNetRequestSource=jstong;
CCNetWorkingDirectory=c:\depot\AppBuilder\1.0\" "/l:ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll;C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts\msbuild-results.xml"]
from which I infer that msbuild was run in the correct working directory and that the command line passed to it was:
/nologo "/p:CCNetArtifactDirectory=C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts;CCNetBuildCondition=ForceBuild;CCNetBuildDate=2009-01-22;CCNetBuildTime=09:25:55;CCNetIntegrationStatus=Unknown;CCNetLabel=3;
CCNetLastIntegrationStatus=Failure;CCNetNumericLabel=3;CCNetProject=AppBuilder 1.0 (Debug);CCNetProjectUrl=http://CISERVER01/ccnet;CCNetRequestSource=jstong;
CCNetWorkingDirectory=c:\depot\AppBuilder\1.0\" "/l:ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll;C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts\msbuild-results.xml"
If I run this manually at the command line I get a similiar error.
It appears to me that the isn't passing the correct command line to the MSBuild executable.
Can you spot my error? Or is this version of CruiseControl.NET (1.3.0.2918) broken with respect to the task?
I think maybe it is your space in the artifact directory path. MSBuild really does not like spaces as it considers it a break between arguments. Can you try an remove the space from that path and see what happens?
Why is your msbuild tag empty? It should be something similar to:
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>C:\dev\ccnet</workingDirectory>
<projectFile>CCNet.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
<targets>Build;Test</targets>
<timeout>900</timeout>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
Without more detail since you don't appear to be specifying a project/solution file which leaves MSBuild assuming one. If you have more than one file that MSBuild is able to use as a project file in that directory that might be causing your issue.DO you have an MSbuild .proj and a .sln file by any chance? Or two solution files?
I had a similar problem and (what Alex said) removing my space did fix the problem. I did however run into another situation where removing the space from a name was not possible. In this case, adding quotes around the name fixed the problem for me.