Unfortunately, I have mixed .NET version projects. Some legacy code is in .NET 1.1 and other is in .NET 3.5. I cannot use
exec { msbuild test.sln }
because msbuild does not support compiling .NET 1.1 solution.
How can I build .NET 1.1 solutions with psake? I think psake is cool and want to utilise it.
On command prompt, I can do
.\devenv.com /rebuild release "c:\engine.sln"
But I can't figure out how I do the same thing within psake build file.
If
.\devenv.com /rebuild release "c:\engine.sln"
is what you do, all you have to do is either make sure devenv is in PATH or supply the full path and do:
exec { devenv.com /rebuild release "c:\engine.sln"}
Related
Xamarin Studio has been replaced for Visual Studio on MacOS. I have a project that builds a DLL using Xamarin iOS. For DevOps (automated release), I want to build the project for release from the command line. I know previously the mdtool was used for this purpose, as seen in this answer but now in visual studio there is no more mdtools binary anymore.
msbuild has replaced mdtool (and xbuild), so all the tasks that once were handled by mdtool are now handled by the cross-platform msbuild and its standard set of cmd-line options.
Release configuration:
Clean a single project in a solution
msbuild /p:SolutionDir=./ /target:Clean /p:Configuration=Release SomeProjectLibrary/SomeProjectLibrary.csproj
Build a single project in a solution
msbuild /p:SolutionDir=./ /target:Build /p:Configuration=Release SomeProjectLibrary/SomeProjectLibrary.csproj
Note: Using Using SolutionDir=./ so these cmds are being run from the root directory of the solution.
My sln is built in VS2017 and contains several .Net Standard class library dll. Build always works successfully in my local machine/virtual machine, with VS UI or just use devenv.com via command-line.
But, when I use TFS to create build task, error about InternalVisibleTo shows.
When I use MSBuild,
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" "C:\WorkArea\xxxxx\_work\1\s\xxxxx\Main\Source\xxxx.sln" /nologo /nr:false /t:"Clean" /dl:CentralLogger,"C:\WorkArea\xxxxx\tasks\MSBuild\1.0.55\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=30268741-631d-4ac8-b4d2-d5b2774b61e7|SolutionDir=C:\WorkArea\xxxxx\_work\1\s\xxxx\Main\Source"*ForwardingLogger,"C:\WorkArea\xxxxx\tasks\MSBuild\1.0.55\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:platform="Any CPU" /p:configuration="Debug" /p:_MSDeployUserAgent="TFS_6e1df8d0-1a29-425d-803c-d70779d0c76a_build_3175_345868"
it has the error:
When I use devenv.com,
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.com" "C:\WorkArea\xxxxxx\_work\1\s\xxxxx\Main\Source\xxxxxx.sln" /build "debug"
it has the error:
Is it a known issue or bug of Current Visual Studio 2017 (version 15.2 - 26430.6)? What's wrong with the AssemlyInfo? What's wrong with the TFS build?
You need to restore NuGet packages before attempting the build to resolve references to the reference assemblies that provide you the core types.
You can do this using msbuild /t:Restore (TFS/VSTS: use msbuild task) or nuget.exe restore (use a nuget.exe >= 4.0.0).
There must be some issue within the latest Visual Studio 2017. They, the Microsoft, change the project file structure of .Net Core / standard a lot from 2017 RC to current one.
How do I build a Visual Micro solution from command line? A standard devenv file.sln /rebuild does not work - it tries to use Microsoft compiler instead of gcc.
I was trying to use the following command to build my solution, but that was giving me an error saying MSBuild target package not found
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"
"C:\Users\FullPath\SolutoinName.sln" /T:Build;package
/p:Configuration=DEBUG /p:OutputPath="obj\DEBUG"
/p:DeployIisAppPath="/bidmc-defaul" /p:VisualStudioVersion=10.0
I have tried MSBuild target package not found but that did not help, then I removed package from target and ran the command and it was successful
Then I ran the following command to create a package zip
"C:\Program Files (x86)\IIS\Microsoft Web Deploy\msdeploy.exe"
-verb:sync -source:package="C:\Users\Full Path\Website\obj\Debug_PublishedWebsites\defaul_Package\myPackage.zip"
-dest:auto,computerName=localhost -allowUntrusted=true
Now this says object of type package and path cannot be created, the zip package could not be loaded, could not find part of the path
Update
fix to my first command to create package. I was giving my solution name SolutoinName.sln, I replaced it with my main project in solution myproject.csproj, with corresponding paths. That resolved my first error.
now second error has changed to "the applicatoin pool that you are
trying to use has the managedRuntimeVersion property set to v4.0 the
application required 4.5"
How should I address this, just install .NET 4.5 on build machine?
It seems you're attempting to build a VS2012.NET 4.5 or higher solution with MSBuild 4.0. That's supported, provided you install the full .NET 4.5 Framework and the required SDK's and targeting packs for VS 2012, VS 2013 and more.
Alternatively, you can upgrade to MSBuild 2013 v12.0 (for VS 2013 solutions support) or MSBuild 2015 v14.0 (VS 2015).
You need to change the VisualStudioVersion to 11 on the MSBuild call.
/p:VisualStudioVersion=11.0
Use IIS Manager to upgrade the .NET Framework version assigned to your app pool (or change your project properties to downgrade the .NET Framework version your web application targets).
My configuration:
VS2010 solution
TFS 2008
Build server - TFS 2008
Build server also has VS2008 Team Suite and VS2010 ultimate installed
TFS 2008 builds my VS2010 solution properly. But when it comes time to run the unit tests I get the following MsTest error.
Using "TestToolsTask" task from
assembly "D:\Program Files\Microsoft
Visual Studio
9.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll".
Task "TestToolsTask" Command:
d:\Program Files\Microsoft Visual
Studio 10.0\Common7\IDE\MSTest.exe
/nologo
/searchpathroot:"D:\Builds\App\Source\86\Binaries"
/resultsfileroot:"D:\Builds\App\Source\86\TestResults"
/testcontainer:"D:\Builds\App\Source\86\Binaries\\Tests.dll"
/publish:"http://tfsServer:8080/"
/publishbuild:"vstfs:///Build/Build/26029"
/teamproject:"Proposal" The
"TestToolsTask" task is using
"MSTest.exe" from "d:\Program
Files\Microsoft Visual Studio
10.0\Common7\IDE\MSTest.exe". No platform specified for publish
operation. For switch syntax, type
"MSTest /help"
MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1.
[D:\Builds\App\Source\86\BuildType\TFSBuild.proj]
The previous error was converted to a
warning because the task was called
with ContinueOnError=true. Build
continuing because "ContinueOnError"
on the task "TestToolsTask" is set to
"true". Done executing task
"TestToolsTask" -- FAILED.
I am not sure what is causing MsTest to fail.
Things tried:
- Provided write access to the build folder to the service account that builds the source on the build machine
You can execute a VS2010 build from within TFS2008's MSBuild, but it looks as if it's using Visual Studio 9.0 TestToolsTask (2008) to try to run a Visual Studio 10.0 (2010) test project (MSTest.exe). I'd try tweaking MSBuild to run the TestToolsTask from the "Microsoft Visual Studio 10.0" folder rather than "9.0", so that the entire process is using the same version of the tools. You can override the tools paths in your tfsbuild.proj file's Properties to ensure the correct version of Visual Studio is used to build with - something similar may apply to the test tools.
Alternatively, it's running the VS2010 test tools correctly, but still trying to use a command line that is specific to 2008 - check the settings and see if you can tweak the command line (you may need to override the MS targets files that is running the build if it's a 2008 version). For example in TFS 2010, a lot of command lines changed from using a simple "server:MyServer" to something like "collection:http://MyServer:8080/tfs/MyCollection". You may therefore have to alter the command line to gain full compatibility with the 2010 version of the tool that is now running, even if it still ultimately points at a 2008 server.
My third suggestion (which isn't necessarily very helpful) is to just upgrade to TFS2010 - it's typically a painless install, vastly better than 2008, and will eliminate any difficulties caused by using a hybrid 2008/2010 setup. (If it helps, I was reluctant to upgrade to 2010 because the 2005->2008 upgrade was 8 days of sheer hell. But in comparison the core of the upgrade to 2010 only took a few hours and "just worked" - the install/upgrade process is much improved)
Jason had the correct idea that lead me down to the correct solution.
In my case, I had to update the "Microsoft.TeamFoundation.Build.targets" to point to "Microsoft.TeamFoundation.Build.ProcessComponents.dll" (VS2010 dll) instead of "Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll" (VS2008 dll)
I also had to make sure that the PlatformToBuild was specified in the TfsBuild.proj file.
Once these 2 steps were done, UnitTests were being run as part of the CI build using TFS2008 and a VS2010 solution.
I have blogged about the solution in detail here: http://blog.aggregatedintelligence.com/2011/03/vs2010-tfs-2008-and-unit-tests.html