I have a solution composed with different projects from different path. We use foundation projects from a vanilla folder and then project specific projects from specific directory. Example:
specific project directory: c:\proj\specific
vanilla project directory: c:\proj\vanilla
vanilla project x path: c:\proj\vanilla\repo\src\project\x\code\
In each vanilla project we have a publish profile that points to the root directory and includes a publishsettings.targets file that has the actual target where the project should be published. By using this structure we can have a lot of projects and publish them using a single target so we don't need to change that target in all projects.
We discovered now that we have a problem when using these vanilla projects as the path used in publish profile is relative to vanilla directory and actually we need it to be relative to the specific project directory (solution directory).
In our publish profile we have:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\..\..\..\..\publishsettings.targets" />
<PropertyGroup>
...
</PropertyGroup>
</Project>
So we need a way to specify the actual sln directory to this path so we can include the correct target so when we do the publish from visual studio it will publish to the specific project and not vanilla one.
I tried finding a "MSBuildSolutionDirectory" but it only seems to be a "MSBuildProjectDirectory" variable that can be used.
Does anyone knows a way I could get the path
Project="c:\proj\vanilla\publishsettings.targets"
to actually be
Project="c:\proj\specific\publishsettings.targets"
by using some msbuild or custom variable and not hardcoding it?
I need it to work both with vanilla (as I have a vanilla.sln) and also with specific project (as I have a X.sln).
Here is a way to make your own version of the MSBuildSolutionDirectory you were hoping to see built in:
<PropertyGroup>
<SolutionDirectory>$([MSBuild]::GetDirectoryNameOfFileAbove(`$(MSBuildProjectDirectory)`, `YOUR_SOLUTION_NAME.sln`))\</SolutionDirectory>
</PropertyGroup>
Notes on the GetDirectoryNameOfFileAbove MSBuild property function:
From http://blogs.msdn.com/b/visualstudio/archive/2010/04/02/msbuild-property-functions.aspx:
$([MSBuild]::GetDirectoryNameOfFileAbove(directory, filename) Looks
in the designated directory, then progressively in the parent
directories until it finds the file provided or hits the root. Then it
returns the path to that root.
From my own testing:
The returned path does not include a trailing backslash.
If the filename is not found, an empty string is returned.
I am trying to exclude certain files/folders from deployment of a web project in Visual Studio Online to an Azure website.
The web project has a Content folder with CSS, JS, build scripts and so on, which are only necessary for development, once deployed to Azure the CSS and JS is loaded from a CDN. Currently the build from VSO is copying all those files to the webroot in Azure, which is unnecessary and a potential security issue in case of the build scripts.
Now I know this can be prevented by setting the build action of a file to None, but this a very tedious solution because there is a lot of development going on, new files get added all the time and it is easy to forget this setting.
First I tried setting the Content folder to Cloaked in the build definitions source settings, but this only causes VSO to not download this folder on build, msbuild will still complain that those files are missing.
Is there a way to tell msbuild to ignore the whole Content folder? I already tried adding /p:ExcludeFoldersFromDeployment="Content" as a msbuild argument in the build definition, and also tried the solutions in here How to get Visual Studio 'Publish' functionality to include files from post build event?, but nothing is working.
I was studying msbuild log files and came up with a solution that is good enough for us to work with.
The first thing I learned was that I cannot prevent msbuild from copying files with build action Content to the output directory, at least not without changing the Microsoft.WebApplication.targets file, which I didn't want to do and am not even sure is possible with VSO build.
Anyway because of this we cannot set the source settings of our Content folder to Cloaked in the build definition, since this will cause the build to fail.
What we ended up doing was described in this answer: https://stackoverflow.com/a/3140349/1230302
So by adding the ExcludeFoldersFromDeployment statement to the .csproj file, the Content folder is excluded from the webroot.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
<OutputPath>bin\</OutputPath>
<ExcludeFoldersFromDeployment>Content</ExcludeFoldersFromDeployment>
</PropertyGroup>
It is not an ideal solution, but at least this way nothing gets deployed if a developer forgets to set the build action to None.
The built in continuous delivery options are designed for convenience. Of you need something custom, like skipping deployment of files that have not changed, then you will need to write something yourself.
You can easily call PowerShell to complete any task from the build process.
If you'd like to customize your build as part of the VSO build system, you can just override your BuildTemplate.xaml file.
Visual Studio Build uses Windows Workflow (xaml) to make a workflow on what the build is supposed to do. You can edit this file and do any modifications to the directory structure before or after the build.
Here is an example.
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.
I am wanting to use Web Deploy to run a custom deployment setup.
As I am wanting to have this work fine when running on many different environments (team members local machines, 4 different builds servers) I want to deploy to a local path that is relative.
What I am wanting to do is:
Deploy to a local relative path
Have the after build step do magical things...
However when i enter the local file path to deploy to as: "..\Deploy_Production"
web deploy complains with this:
2>Connecting to ..\Deploy_Live...
2>Unable to create the Web site '../Deploy_Live'. The URL http://:0 is invalid.
Its as if Web deploy thinks that the relative file path is a website URL. Using "..\" instead doesn't help my cause.
How do you get WebDeploy to deploy to a local relative path?
Edit 1:
I have tried to use a ConvertToAbsolutePath task before build, to no avail:
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<SiteUrlToLaunchAfterPublish>http://mywebsite.com</SiteUrlToLaunchAfterPublish>
<publishUrl>..\Deploy_Production</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
</PropertyGroup>
<Target Name="BeforeBuild">
<ConvertToAbsolutePath Paths="$(publishUrl)">
<Output TaskParameter="AbsolutePaths" PropertyName="publishUrl" />
</ConvertToAbsolutePath>
</Target>
Edit 2:
The above works, but only when running commandline builds against the Solution file not a project file
We have a bug here, when publishing using File system you have to provide a full path. We actually found this bug earlier this week. It will be fixed in our next update. In this case when the relative path is passed it incorrectly thinks that its an IIS path.
As a workaround you can edit the .pubxml to make the publishUrl a fullpath. Fortunately you can use an MSBuild property so that this works in team scenarios. Here is what you should do, edit your .pubxml file and update the value of publishUrl to be the following.
<publishUrl>$(MSBuildThisFileDirectory)..\..\..\Deploy_Production</publishUrl>
This path will be relative to the .pubxml file itself. I've verified that this works from both the command line as well as the publish dialog. If you have any issues with this let me know, but the fix should hopefully be released in a few months [no guarantees of course :) ].
Problem
As part of my csproj I have a custom MSBuild task that executes the YUICompressor and generates a compiled css and js file.
<PropertyGroup>
<CssOutputFile>$(OutDir)..\Styles\compiled.css</CssOutputFile>
<JavaScriptOutputFile>$(OutDir)..\Scripts\compiled.js</JavaScriptOutputFile>
<BuildDependsOn Condition="'$(Configuration)' != 'Debug'">
$(BuildDependsOn);
CompressorTarget;
</BuildDependsOn>
</PropertyGroup>
This runs fine as part of the git deployment and the file is being generated, however the Azure Web Sites deployment engine will then copy all the output files to another folder. In that process it seems it takes whatever you have in your csproj instead of whatever you have in the folder. That menas that the generated compiled.css and compiled.js won't be copied (because they are not in my csproj)
What Azure does to deploy your project should be exactly the same as if you do the following:
Right click on the project and choose Publish
Change the Publish Method to 'File System'
Enter a path and click Publish
So generally, you'll want to make sure that your build process works such that you get the right file when you do this local publish. If it does, then chances are you'll get the same results when git pushing to Azure.
The workaround I used for now is adding an empty compiled.css and .js file to the csproj and I wanted to write this question in case someone goes through the same thing.
It would be great if someone from MS can comment if there are plans on doing something different for this scenario.
Depending on where you place the compiled scripts, you can use star-includes in your project file:
<ItemGroup>
<Content Include="assets\**\*" />
</ItemGroup>
If Azure uses your project file to determine what gets deployed (which seems somewhat strange to start with), then that should work.