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">
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.
I have testaddin.vdproj .I am trying to generate the .msi from that in cmake.But i don't know what command to execute in cmake add_custom_command.Please provide any solution for this problem.
Thanks in advance.
I've never used cmake but I can tell you the only way to build .vdproj projects is by calling devenv.com /rebuild with the correct parameters for your solution / platform / configuration settings. Visual Studio deployment projects aren't MSBuild based so there is no other way to do it. Perhaps CMake has a higher level abstraction for this but under the covers this is what it must do.
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 was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.
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.