MSBuild 16.9 .NET Core 3.1 - OutDir isn't searched for dependencies - msbuild

I'm trying to use MSBuild in a powershell script to build many projects and solutions in a full application suite. I set the parameter for OutDir to point to a single binaries directory and from an output perspective that works.
However the documentation states that OutDir is included in AssemblySearchPaths. But looking at the logs MSBuild is clearly stuck using the hintpath from the csproj file. I've tried setting AdditionalLibPaths as well with no success. This appears to be an issue with building from Visual Studio 2019 as well. My hintpaths point to a common debug directory. A release build still looks in the debug directory. This used to work in older versions of Studio in the .NET Framework days. It worked in older TFS XAML builds setting Output Location to "SingleFolder"
I've also played around with OutDir path ending various quantities of back slashes. I suspect that this old issue is fixed.
How can I get MSBuild to use an alternate directory for the dependencies?
https://learn.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-properties?view=vs-2019
EDIT:
As per the accepted answer, adding OutDir to the AssemblySearchPaths does the trick. For me, I've created a proj file that I've added to each .NET Core csproj files. My thought is that when this gets fixed I can remove the tweak in one place.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<AssemblySearchPaths>$(AssemblySearchPaths);$(OutDir)</AssemblySearchPaths>
</PropertyGroup>

My hintpaths point to a common debug directory. A release build still
looks in the debug directory.
The outdir is always the output folder which does not distinguish between Release and Debug. So you have to use <OutDir>C:\ttt\$(Configuration)\</OutDir> to distinguish between them.
Actually, the system msbuild properties are read earlier than the start of build task. You have to set the properties before the start of build process.
Simply modifying the system properties outdir in csproj will only take effect during the build process, but the system properties are still read before the build starts, also AssemblySearchPaths property read the previous outdir property. So you always take the default values before the modification.
You have to use Directory.Build.props file, it set the values earlier than msbuild start.
1) create a file called Directory.Build.props under your project folder.
2) add the outdir property like these into the file.
<Project>
<PropertyGroup>
<OutDir>C:\ttt\$(Configuration)\</OutDir>
</PropertyGroup>
</Project>
3) restart VS to enable it.
However, I note that it works well in non-sdk net framework projects but it does not list under new-sdk net core projects.
non-sdk net framework projects
new-sdk net core projects
Not sure it is an issue or the Team has forgotten it. Anyway, I have reported it to our DC Forum. You can vote it or add any comments if I did not described it in detail.
As a workaround, you could try to set the new value for AssemblySearchPaths property.
In order not to lose the original value of AssemblySearchPaths, you must add it to csporj file rather than Directory.Build.props file.
Just add these into csproj file:
<PropertyGroup>
<AssemblySearchPaths>$(AssemblySearchPaths);$(OutDir)</AssemblySearchPaths>
</PropertyGroup>
Update 1
I think it is an issue for net core projects.
What I said before is for VS IDE build. Now for MSBuild Command Line, it is another situation.
For non-sdk net framework projects
When I used msbuild xxx\xxx.csproj -p:outdir=c:\ttt -v:diagnostic, it shows this:
Well. It works perfect as we wished.
However, when we used the same command line for new-sdk net core projects, it does nothing. So I think it is quite an issue for net core projects.
And you should note that AdditionalLibPaths cannot be recognized by AssemblySearchPaths.
When I used this under :
msbuild xxx\xxx.csproj -p:AdditionalLibPaths=c:\ttt -v:diagnostic
And you should note that there is no property for AdditionalLibPaths under the list of AssemblySearchPaths property. And it also does not work for net core projects.
In short, it is quite an issue for net core projects no doubt. I also modify the DC ticket.
Now for new-sdk net core projects,
Since you used msbuild command line to set properties, so there is no need to use Directly.Build.props file. MSbuild command line property assignment is actually the same effect of the file.
Also, AssemblySearchPaths is not ready-only. You could modify it. And actually, all msbuild properties can be overwritten and that is a flexible feature of MSBuild.
In summary, you still have to use AssemblySearchPaths.
Solution
Since The Team has some problems with this detail in the net core project, we can use the flexibility of MSbuild to manually modify to get what we want:
1) abandon using Directly.Build.props file and also keep adding these on the net core csproj file:
<PropertyGroup>
<AssemblySearchPaths>$(AssemblySearchPaths);$(OutDir)</AssemblySearchPaths>
</PropertyGroup>
2) use the following command line for net core projects:
msbuild xxx\xxx.csproj -p:Outdir=c:\ttt -v:diagnostic

Related

How can I get GitVersion /UpdateAssemblyInfo to work with ASP.NET Core 2.0 project

We have been using a Bamboo build server for a while now and we have GitVersion installed so it can be selected as a task in the Build plan. We typically use the /UpdateAssembleInfo argument when we run the task. For .NET Framework projects, this would update the assemblyinfo file in the source with the bamboo versioning settings so the .NET assemblies had the same version info as our Bamboo builds and subsequent Bamboo deployment, allowing us to know the version of the deployed project in the field by examining the assembly file properties. This was all working quite well.
However, we are now building and deploying .NET Core 2.0 solutions and are finding that GitVersion /UpdateAssemblyInfo is not working.
I searched for a fix for .NET Core but was only able to find solutions that involved using the project.json file, which is no longer used with .NET Core 2.0 ( it changed to the *.csproj file).
I looked at http://gitversion.readthedocs.io/en/latest/usage/command-line/ and I tried running
gitversion.exe /UpdateAssemblyInfo MyProjectName.AssemblyInfo.cs /EnsureAssemblyInfo
where MyProjectName represents the actual project name suffix for the assemblyinfo.cs file in the .NET Core 2.0 ..\\obj\release\netcoreapp2.0 folder. But it did not update that file.
I have to assume that there has to be a solution for using GitVersion with Bamboo and.NET Core 2.0 but I am having a hard time finding one.
Any ideas?
The latest version of GitVersion provides /updateprojectfiles switch to update version info in the Sdk-style .csproj/.vbproj/.fsproj recursively.
From GitVersion/Usage/CommandLine/Arguments:
/updateprojectfiles
Will recursively search for all project files
(.csproj/.vbproj/.fsproj) files in the git repo and update them
Note: This is only compatible with the newer Sdk projects
It produces the needed attributes even if they are not present in the project files, resulting in following properties:
<Project>
<PropertyGroup>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
<InformationalVersion>1.0.0-versionNumber.N+Branch.branchName.Sha.commitId</InformationalVersion>
<Version>1.0.0-versionNumberNNNN</Version>
</PropertyGroup>
As a workaround, you may consider specifying the assembly info as project properties in .csproj
<PropertyGroup>
<Version>1.2.3.4</Version>
<AssemblyVersion>2.0.0.0</AssemblyVersion>
...
</PropertyGroup>
and then setting values during dotnet build. In addition to its options, the dotnet build command accepts MSBuild options like /property
/property:name=value
/p:name=value
Set or override the specified project-level properties, where name is the property name and value is the property value. Specify each property separately, or use a semicolon or comma to separate multiple properties.
So your build command will be something like
dotnet build /p:Version=1.2.3.4;AssemblyVersion=1.2.3.4

Include additional files in build using MSBuild

In the past we have used a combination of TeamCity and MsDeploy to deploy our projects. We've recently moved into using Octopus deploy, and TeamCity purely for the Build. This meant changing the build process in TeamCity and removing any references to MsDeploy.
In the past we've used confiiguration such as the below in our project file which included additional files and directories:
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
<Target Name="CustomCollectFiles" BeforeTargets="BeforeBuild">
<ItemGroup>
<UCommerceAssemblies Include="$(MSBuildThisFileDirectory)..\..\Resources\UCommerce\ucommerce\*" />
<FilesForPackagingFromProject Include="%(UCommerceAssemblies.Identity)">
<DestinationRelativePath>bin\uCommerce\%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
However this now doesnt seem to get invoked whatsoever. It appears (to me anyhow) that these pipelines were created for use with Publishing from Visual Studio, or using MSDeploy, however we need to just include these files in the directory either before or after the build has taken place. There seems to be tons of references across the web about doing this, however they all refer to using MSDeploy.
Can anyone shed any light on how I can include additional files/directories in the build without using MSDeploy?
Thanks for your time in advance
dotdev
As you are using Octopus for deployment you only need to include additional files (reference assemblies, etc.) into code package sent to Octopus.
To do this one needs to use OctoPack for project packaging. Then add .nuspec file into the project, for example this line in .nuspec will add all files from some different location into the .nupkg package under "bin\additional" and will be deployed correctly by octopus.
 
Nuspec docs
Similar solution is discuses here.

MSBuild task does not build solution file

I have a project file that should build another solution. I tried using the MSBuild task for this, like this:
<MSBuild Projects="MySolution.sln" Properties="Configuration=$(Configuration)"/>
I tried a lot of variants, like supplying hardcoded configuration, target Rebuild and so on. Building reports an error when I pass a wrong solution name, non-existing configuration or target and so on, so it definitely loads the solution and the project files. It exits relatively fast though and produces no output. According to documentation and examples, this should work though. I also tried passing an ItemGroup for the project, including project-specific properties as suggested by examples or in MSBuild - How to build a .NET solution file (in an XML task script) from pre-written command line commands , but that does not work either. It runs without error but no output.
When passing a list of project files instead (or a single project file), it builds correctly, but the problem is that dependencies between the projects are not properly resolved. At the end, I have to supply all project files in the solution and add them to the list, which is what I want to avoid.
So, why does solution building not work, even though it should? What is wrong here?
Is this a .net project? If so you probably need to pass in a platform as well as a configuration.
<MSBuild
Projects="MySolution.sln"
Targets="build"
Properties="Configuration=$(Configuration);Platform=$(Platform)" />
If the project just contains web sites and libraries then the platform should be Any CPU if your solution just contains executables then x86 or x64 or if it's a mixture of different types of platform then you can use mixed platforms
To check what are available open the solution in Visual Studio, right click on the solution in solution explorer and select "Configuration Manager" you'll then have a drop down for "Active Solution Platforms"

The OutputPath property is not set for project

Building my Jenkins/MSBuild solution gives me this error
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(483,9): error :
The OutputPath property is not set for project '<projectname>.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Latest' Platform='AnyCPU'. You may be seeing this
message because you are trying to build a project without a solution file, and have
specified a non-default Configuration or Platform that doesn't exist for this project.
[C:\<path>\<projectname>.csproj]
Any ideas?
EDIT
I have this in my .csproj file
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Latest|AnyCPU'">
<OutputPath>bin\Latest\</OutputPath>
</PropertyGroup>
I have figured out how it works (without changing sln/csproj properties in VS2013/2015).
if you want to build .sln file:
/p:ConfigurationPlatforms=Release /p:Platform="Any CPU"
if you want to build .csproj file:
/p:Configuration=Release /p:Platform=AnyCPU
notice the "Any CPU" vs AnyCPU
check the code analysis, fxcop, test coverage(NCover) targets, as well as the MSBUILD should be located properly. In my case its:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
but it can be different as you can see microsoft has given 6 cmd options to build code base::AMD (with cross plt, x86 & x64 options) and Windows(cross, x86, x64) and that also when code development happened with default JIT (it can be PreJIT ngen.exe, econoJIT)
I think more than this troubleshooting can be handle using power shell + msbuild. May be helpful for someone ...
Open up your csproj in a text editor and see if you have a property group section, should look something like this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Latest|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Latest\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
Do you have a 'Latest' build configuration? If not add the above section to the csproj.
As mentioned by perlyking, rather than editing the csproj XML The following worked for me. Here are the steps I used.
Open the Project Properties.
Select the Build Tab.
Under the Output section, Check that an output path is set. (if not set one, save the project and it should work).
If it is set, click on the "Browse..." button of the output path.
When the folder selection dialog opens, Navigate up one level in the
file browser and then re-select the output folder and click
the "Select Folder" button.
Save the project properties and it should work.
To add to what #James said, I found that if I looked at the project Compile properties in VS2013, the Build Output Path was specified. But when I examined the .csproj file directly, the OutputPath element was missing for the relevant build configuration. So in VS I simply made and reversed a minor edit to the output path, saved it, and that kicked the value into the project file, and I was then able to build.
I was using MSBuild to build multiple .sln files, and had added a new step to build a .csproj file as well, when I encountered this error.
#Saurabh's answer highlighted the root of the problem. However, when fixing it, adding /p:Platform=AnyCPU to the MSBuild Arguments section didn't fix it. I actually needed to update the Platform value on the build step.
All other build steps were using the $(BuildPlatform) variable value (which happened to be "any cpu", with a space in it).
(Had I been building multiple .csproj files, I probably would have created a second variable for the AnyCPU platform.)
For me the answer was to fix all the projects in Build > Configuration Manager.
If you have some projects where the name or platform does not match the solution configuration, you should change it so they all match.
I was running into this issue while updating an older project with additional project configurations for per-environment config transforms.
It turns out that when the project configurations were added to the csproj file, they were inserted after an Import element which caused the issue.
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'ProjectName.Dev|AnyCPU'">
...
Moving the Import element after all the PropertyGroup definitions fixed the problem for me.
Relevant similar case: https://stackoverflow.com/a/31072208/2452820
I got this error only when I was publishing my web project. I had mistakenly selected the wrong build configuration when setting up the publish profile.
I had same issue. I have updated my windows platform by using command line. Currently i got updated to windows#5.0.0 version. Then you need to search for file name "SQLite3.UWP.vcxproj". Try to change "v141" to "v140". Currently I am using Visual Studio 2015 professional. If it's Visual Studio 2017, then there is no need to change version in SQLite3.UWP.vcxproj file.
In my case this error happened because the output folder included a dot to make it relative to the current directory. The problem was solved by removing the dot.
The offending Build output path was:
.\bin\Output
The problem was solved by changing it to
bin\Output
The build output path can be found in the Build tab of the project properties, and there is a different path for each combination of Configuration and Platform.
Just had the issue for some service fabric stuff in MSBuild.
First step was right clicking each affected project and pulling up their Properties, selecting the Build tab, then setting the platform target to x64.
Second step was to go into the configuration manager and set each project to also use x64 for Debug and Release.
This was for a VS2017 project.
I had the same problem on a few projects. After adding a new configuration to the projects, the PropertyGroup was added at the very end of the Project file.
Moving the PropertyGroup to right after all the other configurations PropertyGroup fixed the issue.
I hope this helps.
I had this witha slightly unusual SLN/CSPROJ file arrangement:
I had project files:
A.csproj, with configurations "Dev" and "Production"
B.csproj, with configurations "Dev" and "Production"
C.csproj, a "common" library used by both A and B with configurations "Dev" and "Production"
And I had SLN files:
AC.sln, with configuration "Production" - this is used by jenkins to build project A and the common library
BC.sln, with configuration "Production" - this is used by jenkins to build project B and the common library
ABC.sln, with configuration "Dev" - this is used by developers in VS to write new code without having to keep opening different solutions (this answer is a simplified view of a 55-project solution)
I'd made an edit to the common library and introduced a dependency on project A. AC.sln would still build in jenkins but BC.sln gave an error saying:
The OutputPath property is not set for project 'A.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Debug' Platform='AnyCPU'.
It was initially puzzling because we don't even have a Debug config anywhere in any project; find in files for Debug| turned up 0 hits
ABC.sln that the human developers use in VS would also build fine. Building BC.sln gave an error that A.dll wasn't found
When the circular irresolvable problem of C depending on A was removed, everything started working again
This error is misleading and can be caused by a different issue. Check the entire message:
The OutputPath property is not set for project 'myproject'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='myconfig' Platform='AnyCPU'. This error may also appear if some other project is trying to follow a project-to-project reference to this project, this project has been unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform.
My build configuration was missing this node in the csproj:
<PlatformTarget>AnyCPU</PlatformTarget>
Despite saying AnyCPU was the selected Platform in the dropdown, the actual xml was not there. Adding it fixed the mismatch between the project and the other project it was referencing.
The OutputPath property is not set for project error message will appear if a Platform environment variable exists (as seems to happen on HP laptops) and the target of MSBuild contains a reference to another Visual Studio project.
After renaming the Platform environment variable my build now works.
It seems the parameter /p:Platform="Any CPU" gets applied to the target solution but doesn't 'carryover' to referenced projects. In my instance, the error message indicated referenced projects were using the environment variable Platform=MCD.
I had two project configs, Debug and Release. When the Release build was used, it was throwing this error. The issue I found was that in the csproj file, the Debug config was near the top and the Release config was all the way at the bottom.
Manually moving the Release build just below the Debug build fixed it.
I'm assuming I did something incorrectly when setting up my build configurations because this doesn't feel like something I should have had to manually adjust.
Edit the properties of the project:
Make sure "Configuration Properties->General->Output Directory" is not blank. Note, it's not called OutputPath here. You can probably copy the value from Intermediate Directory.
I encountered the same problems when build TheXTech (https://github.com/Wohlstand/TheXTech/wiki/Building-on-Windows#building-in-visual-studio-201520172019-and-cmake) recently. And finally I found it is a cmake -A issue. The correct arch for 64 bit on windows is x64, not Win64.
For some more reference, see https://cmake.org/cmake/help/v3.16/generator/Visual%20Studio%2016%202019.html#platform-selection, https://cmake.org/pipermail/cmake/2019-April/069379.html.
Go to Solution properties and change the configuration to Any CPU or X64 or X86, and if build is checked uncheck that for what you are getting error for. By default, project build that for build configuration in solution and throw error as mentioned when building the project.

Problems with MSBuild OutputPath and OutDir in TFS2010

We have a very large solution (some 300+) projects and we are trying to build it via MSBuild on TFS2010.
We can build it via MSBuild on all out development machines, and are in the process of adopting TFS.
The structure of our code is like so:
bin\Client
bin\Server
Framework\ClientFramework.csproj
Modules\Module1\Project1
Modules\Module2\Project2
etc.
Each project has a relative OutputPath which builds the code to the bin Client or Server directory. So for example, Project1.csproj has an OutputPath of "..\..\bin\Client".
We seem to be having a problem that in TFS MSBuild the OutDir is set to a Fixed Path:
C:\Builds\MyProject\Binaries\
So things are getting confusing when resolving the relative OutputPath on top of the OutDir
ClientFramework goes to C:\Builds\MyProject\Binaries\..\bin\Client
Project1 goes to C:\Builds\MyProject\Binaries\..\..\bin\Client
etc.
We also have some Post build events that copy some 3rd Party dll's to the bin folders, these paths cannot be resolved properly either.
I think the solution we are after is to build everything to our existing bin\Client, bin\Server structure and then move the Folders from bin to Binaries.
Any ideas on how to accomplish this or how we should be working, are appreciated, but updating our existing projects might prove problematic, as it all works with VS, developer command line builds and with CC.net.
Since this is first link that pops up with a Google search of "TFS OutDir", I must provide a newer solution. I spent an entire day playing around with OutDir, OutputPath, and overriding them with TeamBuildOutDir. A better solution is to set the MSBuild property GenerateProjectSpecificOutputFolder. It comes with .NET 4.5. More info here: http://blog.codeassassin.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/
I found the answer on MSDN : http://msdn.microsoft.com/en-us/library/ff977206.aspx