How can I, through the .csproj file, specify environment variables to apply during the build, such as when building with Rider?
Specifically, I want to set DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 so that I can build from within the IDE, without resorting to the command line (see below).
Adding <InvariantGlobalization>true</InvariantGlobalization> to the project file did not work, since that does not affect the underlying/imported build target, but executing export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 before dotnet build NAME.csproj worked.
Background: A recent distro upgrade on openSuse Tumbleweed bricked MonoGame project builds with the following error message when invoking mgcb (re-installing ICU with Zypper did not fix the issue):
Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.
(...)
error MSB3073: The command "dotnet (...) exited with code 134
Edit: I have finally gotten a Target to run before the Nopipeline target using InitialTargets. The problem now is the Exec task runs in a discarded scope.
Depending on which task fails, you can hope that the target author added an option to set the environment variables.
E.g. for C# compilation, you could set:
<PropertyGroup>
<CscEnvironment>$(CscEnvironment);DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1</CscEnvironment>
</PropertyGroup>
If the tool is run by a custom target, you would need to author a replacement target that allows setting the environment variable.
Related
I'm looking for a way to integrate clang-tidy into a CI workflow, but the build system being used is MSBuild with dependencies managed by vcpkg in manisfest mode.
Is there some advanced command line that I can pass MSBuild (or some other tool that understands MSBuild process completely) to be able to generate compile_commands.json?
I'm sure I'm not the first one to try that, I've seen a couple of cases of success using SourceTrail and ClangPowerTools, but it has been specially painful in my case because the alternatives cannot detect the include paths exposed by vcpkg.
It turns out that msbuild has a builtin target for clang-tidy since Visual Studio started to support that linter.
To invoke it one can run : msbuild /t:ClangTidy ....
Unfortunately, very few command line options are exposed from the clang-tidy integration to msbuild CLI: the list of checks, the header-filter, additional compiler options, a flag for warnings in system headers and the tool path.
If one wants to export the fixes file generated by clang-tidy, which was my case, it needs to do some extra work.
I achieved my goal by adding one Directory.Build.props file in the project folder which overrides the path to the original clang-tidy.exe with a batch script (.bat), which does some preparation steps and forwards the msbuild target command line to a python script which can invoke clang-tidy with its full command line capabilities.
The props file:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ClangTidyToolPath>$(where_I_saved_the_bat_file)\</ClangTidyToolPath>
<ClangTidyToolExe>msbuild-clang-tidy-runner.bat</ClangTidyToolExe>
</PropertyGroup>
</Project>
The batch file:
SET PYTHONPATH=...
REM and maybe other stuff
python3 -m my_custom_clang_tidy_runner %*
Interestingly the batch file was the only way other than a real executable file that I could place in the Directory.Build.props that wouldn't result in msbuild compilation error. I tried python and powershell scripts and none were accepted as a suitable clang-tidy executable file. I experimented creating a C++ program which does the same as my Python script and it worked as expected as well.
So, to summarize, the recipe is:
Create the Directory.Build.props file in the root folder of the project you want to lint overriding the clang-tidy path.
A custom .exe or .bat file to replace clang-tidy capable of forwarding the command line options passed by msbuild together with any customisation you wish.
Invoke msbuild /t:ClangTidy ... and Bob's your uncle!
I have configured a TFS(2017) build pipeline to compile a VS extension with debug mode for a specific requirement which require .pdb files.
The build solution task fails for "debug" configuration with below error, however same pipeline works for the release configuration.
I have tried the approach mentioned in the following discussion as well, howewer it doesn't resolve my issue.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/fd220999-5761-475a-bf86-98dff6b35218/unable-to-compile-vsix-project-that-is-a-part-of-my-solution-using-amd64-msbuild-from-vs2015?forum=msbuild
Appreciate if someone can help me to resolve this issue.
Following is the build configuration used for the Build Solution task:
Following build variables are used to configure build parameters.
Build Error message:
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets
(633, 5)
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets(633,5):
Error VSSDK1077: Unable to locate the extensions directory. "Value
cannot be null. Parameter name: path1". Process 'msbuild.exe' exited
with code '1'.
Update your Microsoft.VSSDK.BuildTools NuGet package to latest version 15.9.3032, just in case it is a problem already solved.
Release configurations can also generate PDB files (Project properties, Build tab, Advanced...button, Output > Debugging information). So, if the Release configuration works for you, you can keep using it while also generating a pdb file with full debug information.
The error is happening when, once compiled correctly, the generated VSIX output file is going to be deployed to the folder for extensions of the experimental VS instance, which is a required step to debug the VSIX file. A possible explanation of the different behavior for Debug/Release configurations is that maybe your .csproj specifies <DeployExtension>False</DeployExtension> for the Release configuration. By default, if not set, that property is set to true in the Microsoft.VsSDK.targets file:
<DeployExtension Condition="'$(DeployExtension)' == ''">true</DeployExtension>
Since likely you don't need to deploy the VSIX to the VS experimental instance when building on a build server (because you are not going to debug it), you can set that property to False to skip the deployment. This can be done with a 3rd build configuration (ex: "DebugBuildServer"), for which you specify DeployExtension to False in the .csproj file, or sticking to two build configurations but passing the /p:DeployExtension=false in the MSBuild arguments of the Visual Studio Build task of your build pipeline.
I have a C# solution with VS 2017, containing an app project and a test project. I can use the "create app package" wizard to create one single bundle for x86 and x64. However, I would like to automate this process, which means I need to use msbuild in command line to do the same work.
With the reference from here and here, I got:
msbuild .\MyProject.sln /p:AppxBundle=Always /p:AppxBundlePlatforms="x86|x64" /p:Configuration=Debug
But I will get errors for my test projects, like:
MakeAppx : error : Error info: error 80080204: The package with file name "Tests.XXXX.Shared.Uwp_1.0.0.0_x86_Debug.appx" and package full name "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx_1.0.0.0_x86__xxxxxxxxxxx" is not valid in the bundle because it has a different package family name than other packages in the bundle. The expected package name is xxxx-Test.xxxxTestApp....
My guess is that I should not use "Always" for AppxBundle, but I cannot find any document online mentioning how to set this value as "If Needed". I also tried to add "Never" in project properties for the test project, but the command line argument seems to overwrite that.
So my question is: How to exclude a test project from the solution when creating a bundle using msbuild in the command line?
How to exclude a test project from the solution when creating a bundle using msbuild in the command line?
To resolve this issue, you can build the project file directly when you create a bundle using MSBuild in the command line:
msbuild .\YourProjectFile.csproj /p:AppxBundle=Always /p:AppxBundlePlatforms="x86|x64" /p:Configuration=Debug
Alternatively, you can open test project file and add the following properties at the end of the first <PropertyGroup> element to exclude the test project to be included:
<PropertyGroup>
<AppxBundle>Never</AppxBundle>
</PropertyGroup>
Check this thread and the document for some more details.
Hope this helps.
Our continuous delivery set-up, until recently, was delivering Service Fabric packages using the following command:
msbuild SFApp.sfproj /t:Package
This was necessary because the target Package is unavailable at the solution level. I.e. The command
msbuild SFSolution.sln /t:Package
Fails, as the target does not exist.
As our dependency mesh grows, it gets to a point in which most interfaces projects will not build without a solution file (to work around the "OutputPath does not exist" red herring). There seems to be a way to do that according to this answer. Unfortunately, while targets like Clean work…
msbuild SFSolution.sln /t:SFApplication:Clean
(…snip…)
Build succeeded.
0 Warning(s)
0 Error(s)
…the target Package won't!
msbuild SFSolution.sln /t:SFApplication:Package
(…snip…)
Build FAILED.
"SFSolution.sln" (SFApplication:Package target) (1) -> SFSolution.sln.metaproj :
error MSB4057: The target "SFApplication:Package" does not exist in the
project. [SFSolution.sln]
0 Warning(s)
1 Error(s)
(Solution/project folders/names omitted/paraphrased for clarity. I can provide the actual logs if necessary.)
So the question is: how could I, using the Command Line, build one project using the Package target and the solution file?
Or how can I otherwise package a Service Fabric application from the command line?
It's bad idea to compile sfproj file(and any other project file) without sln, because it can bring wrong content to its output from referenced projects. Only solution has a knowledge about what project to compile in what configuration.
To make Package similar to "Right Click->Package" in VS:
Just add to your sfproj the following target
<Target Name="ForcePackageTarget" AfterTargets="Build" Condition="'$(ForcePackageTarget)' =='true'">
<CallTarget Targets="Package"/>
</Target>
And then running normal build on solution you may trigger the package step by /p:ForcePackageTarget=true :
msbuild yoursolution.sln /t:Build /p:ForcePackageTarget=true /p:Configuration=Release /p:Platform=x64
Actually it performs two-in-one steps, build and package, with respect to Solution Configurations on all referenced projects
MSBuild only supports a small set of target names that can be specified at the solution level. As you've discovered, Package is not one of them. You'll need to execute two separate calls to MSBuild: one which builds the solution and one which calls the Package target on the sfproj. The Package target of an sfproj has a dependency on the Build target so it will ensure that the sfproj and its project dependencies are built.
I had the same problem and fixed it by changing the Platform in the failing projects to explicitly build for x64.
Click Build > Configuration Manager and make sure that the assemblies are compiled for the x64 platform, that should also set the Output Paths in the corresponding .csproj files.
The actual command line action that is being executed is this:
"C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe" "C:\agent\_work\1\s\Project\SFProject.sfproj" /t:Package /p:platform="x64" /p:configuration="release" /p:VisualStudioVersion="14.0"
Use the below script.
C:\Program Files (x86)\Microsoft Visual Studio 14.0> msbuild "Fabric.sfproj" /t:Package /p:Configuration=Release
Service fabric requires Target to be set in x64 platform,
So change all you reference projects target to x64 platform.
you can do this by using configuration properties of your solution. If x64 is not listed in 'Configuration Properties' click configuration manager in the same window and under platform column for the required project add new project platform as x64.
Hope this works for you.
We have had the exact same problem as you had and I have been looking around for a solution all over the web and did some experiments. Those are the steps that worked for us:
Don't manually add a target anywhere as suggested by other answers on StackOverflow. Not necessary. Especially in a CI environment, you want to build the projects separately anyways.
Prepare the projects in the Solution: Change the target platform for all projects to x64
Build the application
msbuild.exe SFAplication.xproj /p:Configuration=Release /target:rebuild
Package the App
msbuild.exe SFAplication.sfproj /p:Configuration=Release /target:Package
My goal is to use a script/CMake to create a "Debug" build configuration and a "Release" build configuration that can be switched between within Code Composer Studio's UI (using the "Build Configuration -> Set Active..." option).
Currently,
A script is ran that runs CMake with desired commands (toolchain, etc). A Code Composer Studio project is generated (as described in CMakeLists.txt)
CCS project is imported into CCS
The problem is this only generates a "Debug" build configuration. Is it possible to add a command to CMakeLists.txt, or to cmake command line, or even ccs command line that allows multiple build configurations to be generated?
The only difference between the two will basically be defining NDEBUG, and possibly changing optimization level.
I had this same question...then realized I am the one who originally asked this ~4 years ago! Anyways, I found a way to do this:
Using Code Composer, create the build configuration(s) as you want them to behave. When done, copy the .cproject file to a cproject.in "template". CMake will use this template to generate an identical .cproject for any future cmake builds. Make sure to replace any hardcoded values (ex: project name) with proper cmake variables.
For me, my CMakeLists.txt called configure_file(path/to/cproject.in ${CMAKE_SOURCE_DIR}/.cproject #ONLY).
Also be sure to delete your CMakeCache and CMakeFiles if they already exist...I believe those were preventing me from seeing the resulting change.