Is there a way to set /framework:net-4.0 in nunit-console.exe.config like in GUI? Or any other way to run NUnit tests with MSBuild Community Tasks?
I thought that this solution was applicable to NUnit GUI only, appearently it is applicable to any .NET application. So to answer my own question, all you have to do is
add <startup>
<supportedRuntime version="v4.0"/>
</startup> to nunit-console.exe.config and you don't have to specify it as a command argument.
Related
I'm working on a PS Binary module and I developed it using PS 7.1. I tried importing the dll into PS 5.1 and I got the following error:
ipmo : Could not load file or assembly 'System.Management.Automation, Version=6.0.4.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
My .csproj file is as follows:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFramework>netstandard2.0</TargetFramework>
<AssemblyName>assemblyName</AssemblyName>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="PowerShellStandard.Library" Version="5.1.0-preview-06">
<PrivateAssets>All</PrivateAssets>
</PackageReference>
<PackageReference Include="System.Management.Automation" Version="6.0.4" />
</ItemGroup>
</Project>
This project is created by using the PowerShell Module Template via dotnet cli: dotnet new psmodule.
You did it backwards. If you want a module to be compatible with both Windows PowerShell and PowerShell Core, you need to develop it against PowerShell 5.1, then use the Portability Analyzer to determine how portable your module is.
System.Management.Automation houses most, if not all, of the PowerShell specific constructs. If you build against PowerShell Core, PowerShell 5.1 is NOT going to have the same version of that assembly loaded into memory. Hence, it cannot find the assembly version it is looking for.
Here is some more information you may find useful on the subject.
Edit:
If your module is not compatible both ways, you can develop it for PowerShell 5.1 anyways and use the WindowsCompatibility module from PowerShell Core which should implicitly make use of constructs only available in Windows PowerShell. There are some caveats, the module must not use "live" objects (like CIM, remote connections, etc.) and the module will effectively remain "Windows-only" since you can't run PowerShell 5.1 on Linux or MacOS.
While making a build automation I came across an issue. Along with upgrading Visual Studio 2013, the path to MSBuild has moved as described here http://timrayburn.net/blog/visual-studio-2013-and-msbuild/
I've updated my system path to point to this new location for msbuild. Using a regular cmd prompt msbuild resolves just fine. But running my scripts in powershell, it seems to still pick up the old one, and showing the issue as described in the link. How can I see and change where powershell and psake picks up msbuild from, so I can point to the expected version?
PSake supports more MSBuild versions on one box. You can choose version and platform eg. 4.0x64 with framework directive. Path to MSBuild tools is not taken from $env:path but is computed. It uses registry to find proper path.
VS 2013 and MSBuild Tools are supported since PSake 4.3
In PS type [Environment]::GetEnvironmentVariable("Path")
Do you see both paths? In what sequence do they appear? What occurs in cmd vs ps when you switch the order?
I have a Visual Studio project that was originally configured to build using the Release|Any CPU build configuration.
I need to change this so all the assemblies are built using Release|x86.
I can change this in Visual Studio but how do I specify the equivalent in my nant build script?
EDIT: I am building my assemblies using the csc task.
My experience might be outdated (did this 3 years ago), but the NAnt <csc> documentation still supports it: this is not possible in a simple way.
We've solved this by running corflags on the output assembly after build to set the 32BIT flag. You can do this from NAnt, with the <exec> task. CorFlags is installed as part of the SDK, so you should have it already.
I am using nant 0.92 version. I have solved the problem using platform attribute of csc/vbc compiler tag.
<csc target="library" output="xxxx.dll" platform="x86" verbose="true" debug="true">
<vbctarget="library" output="xxxx.dll" platform="x86" verbose="true" debug="true">
Trying to configure NUnit 2.5.8.10295 in Cruise Control.NET on Windows Server 2008 R2, .NET 4.0, my NUnit task times out, and nunit-agent.exe seems stuck running. It works fine from the command line.
The only solution I've found is to define the environment variable COMPLUS_Version.
Is there a better solution to this problem?
C:\builds\nunit\bin\net-2.0\nunit-console-x86.exe
C:\builds\testLogs
C:\builds\build\NUnit.Tests\bin\Debug\NUnit.Tests.dll /nologo /framework=4.0.30319
10
0,1,3,5
COMPLUS_Version
v4.0.30319
I tried various edits to nunit-console-x86.config, but nothing worked but this awkward looking "solution".
Thanks
You are most likely running into the known bug reported here https://bugs.launchpad.net/nunitv2/+bug/602761 Your setup is identical to our setup as posted (comment 1). Your fix is the one suggested by the project maintainer. The other option is to not use the nunit-agent and force nunit console to run as .NET 4.0
My buildbot has been running for 3 years using devenv.com to compile the projects on Windows.
Now devenv.com has troubles to build for 64 bits versions: passing the configuration as "Debug|x64" generates command line errors because of the pipe character. Escaping and enclosing between quotes result into other errors, some because of the spaces in the directory names, some because of strangely understood command line.
I tried both vcbuild.exe, and MSBuild.exe. vcbuild.exe works perfectly: I'd like to stick to it. MSBuild.exe, on the other side, has a completely strange and complicated output that my coworkers feel terrible. But it is touted everywhere as THE way to build.
The question is: which of devenv.com, vcbuild.exe, and MSBuild.exe is the method that is most likely to last in time?
MSBuild (before Visual Studio 2010/.NET 4) doesn't itself build C++ projects. It calls out to vcbuild.exe. So if you are happy not using MSBuild then I would stick to that for the C++ projects. For managed projects (and for C++ using VS 2010) use MSBuild.
MSBuild is the method "most likely to last". VCBuild.exe is dead; it's last release was 2008. MSBuild 4.0 will still use it, if it needs to build a VC project from VS2008 or earlier. As for devenv.exe -- of course, it's just headless Visual Studio. Functionally it is the same as hitting build in VS. That means that these days, it's essentially just handing off to MSBuild, but sometimes with less parallelism than msbuild.exe will get. The main reason you might still have to use devenv.exe is .vdproj (Deployment) projects. These legacy things have a build process hard coded into VS. I recommend an alternative like WiX or Installshield which are MSBuild based. Not long now until everything build in VS is MSBuild.
In short -- MSBuild is the future, use it unless you have deployment projects or other special circumstances.
Dan
I ran into the same problem, and solved it by Windows-shell-escaping the pipe character:
"Debug^|Win32"
msbuild.exe does not (did not?) know how to build setup projects. devenv.exe does.