My goal is to override the OutputPath property on all projects in a solution to be $(SolutionDir)$(Configuration)\. I would like to set this from within the VS2015 IDE.
I don't want to change the OutputPath in the .csproj or .vcxproj files (I know how to do this and it's not my intention to make a permanent change to the project files). I just need a local change for the moment to build.
I know I can accomplish this from the command line in a Developer Command Prompt by setting /p:OutputPath=$(SolutionDir)$(Configuration)\ on msbuild. Ideally, would like to be able to do this from within the IDE. Is that possible?
I was able to set OutputPath in a Developer Command Prompt and then launch VS2015, open the solution, and build:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe"
Typical way of doing this is to import the same msbuild file in each project, and set OutputPath in that imported file. Disadvantage: project files need to be modified, it's not 'from within VS'. Advantage: has to be done once only, works on commandline as well as in VS, works for everybody, is pretty flexible and extensible. For example you could override OuputPath based on whether or not a certain file is present on the system, or a certain environment variable, or hostname, etc.
The answer you gave also works, though is also not from within VS. But the biggest drawback for me is that if you give your project to someone else they won't have an overriden output path, i.e. such modifications cannot really be put in version control. Of course if that's what you are after than it's fine.
Related
I must put this program into production today, and I can't get it to run independently.
In the program, I have included NuGet package "Imports ClosedXML.Excel" and use it to create spreadsheets. When I build my executable, and try to run it from another computer, it cannot find the ClosedXML and Documentformat.OpenXml assemblies.
I checked in References that "Copy Local" was = True for ClosedXML and Documentformat.OpenXml, but it's not working. I found another website that mentioned Global Assembly Cache, and that if the dependency is in there, it will not be included in the Build .exe.
I am running Visual Studio Professional 2017. I am in over my head on this one, so if you have answer (and I hope you do), please try to provide it in elementary terms I can understand.
Sometimes issue is solved by individually adding application files inside the following menu
Go to Publish-->Application Files
Select Show all files
Under Publish Status
Set the files you need to Include [not include(auto)]
I'm in the process of updating an old solution from Visual Studio 2005 to Visual Studio 2015, and I'm trying to reproduce as much of our old kludgy behavior as we safely can to minimize the downstream effects. I'm currently running into an issue with the Website Property Pages and MSBuild.
The path here is mostly correct, except that we want the configuration used to be in the path as well. So a Debug build will go into E:\Projects\...\PrecompiledWeb\Debug\MyService and a Release build will go into E:\Projects\...\PrecompiledWeb\Release\MyService. Is this doable? Is there a variable I can insert to make that determination when building?
We're using msbuild against the containing solution file (via TeamCity if it matters, but I can replicate it without it).
Edit: I've found the Debug.AspNetCompiler.TargetPath and Release.AspNetCompiler.TargetPath paths in the solution, but if I change them to be separate, the Debug one overrides the Release one when I next open the dialog.
When MSBuild starts building the project, it takes one or several project files. This dialog takes it parameters from MSBuild project file (you can edit it either from Visual Studio, or simply in every text editor). The project should have the property, called $(Configuration). You can use it in your output variable:
<OutputPath>E:\Projects\...\PrecompiledWeb\$(Configuration)\MyService</OutputPath>
One thing you must aware of is that the property $(Configuration) must be declared before the $(OutputPath) property.
I am using MSbuild to create a deployment package (simply copying various files from the projects in my solution to different folders) I would like the root folder to be of the format
DeploymentPackage2.3.4.5ForRelease
How can I get MSbuild to put the Assembly number in the folder name automatically?
EDIT:
The solution has a great deal of projects in it (too many really) they all get their version number from a SharedAssemblyInfo.cs file that is manually updated but in the fullness of time will pick up the svn build number (but that is a job for later)
I am building using an external .bat file that calls a custom written .targets/.proj setup that simply calls msbuild on the .sln of the solution.
The 'create package' step I am trying to create happens after a succesful build and will eventually be run by our CI framework, however I would like to be able to run it locally too.
I have created a "CreatePackage" target that does the copying that I want, however it is currently into a fixed folder. I need the folder name to reflect the AssemblyVersion of one of the final dll's.
If there is a better way then I want to know about it... but I am going to use this I think
MSBuild Task to read version of dll
Elsewhere on the Web, you can find recommendations on using something like this to simulate the Publish feature in the VS 2005-2008 IDE from a command-line (I hope I did not goof up the syntax!):
msbuild /t:ResolveReferences;_CopyWebApplication /p:BuildingProject=true;OutDir=C:\inetpub\wwwroot\ blah.csproj
Now, it looks like the .dll's copy fine. However, there are certain configuration files and template files that are copied to the bin folder which are needed for the app to work. For example, an NHibernate configuration file shows up in blah.csproj as:
<None Include="blah.cfg.xml">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
While using Publish from within the IDE copies this file as it should, the aforementioned _CopyWebApplication target does not. I need this file to be copied in the build script. Is this desired behavior for _CopyWebApplication? Any recommendations on how to fix this?
EDIT 4/21/2010:
Let me clarify that we are limited (for now) to VS 2005 and VS 2008 projects, and that our build scripts are written for MSBuild 3.x. We are not yet ready to move to VS 2010.
Let me also specify that we are looking for a solution available from within a command line so that we can automate a Publish-like command along with custom build options, and possibly automate deployments down the road.
This is just a workaround.
In the build script for publishing Web sites, after running MSBuild on the Web project itself to publish it (Targets="ResolveReferences;_CopyWebApplication"), I added a copy operation:
<Copy SourceFiles="#(ProjectBinFiles)" DestinationFolder="$(StageBin)\%(ProjectBinFiles.RecursiveDir)" />
where ProjectBinFiles is an Item representing the files in the bin directory in the source directory, and StageBin is a Property representing the bin folder in the published site's directory. So far, it seems to work.
I was having a similar issue as well. I think the answer is using MSDeploy. Investigating it now, but may provide functionality required...
I had this same issue in VS 2012 and eventually fixed it by doing the following to any files which needed to be copied:
Set the Copy to Output file property to Copy if newer
Set the Build Action file property to Content (or Compile if the file needs to be compiled)
I know that the latest book out on MSBuild says this is not possible, but I am sure I have seen a property that points to the current file.
Does anyone know a way to find the current file? (ie When the main MSBuild file imports a secondary file. What is the path to the secondary file from inside that file.)
I am trying to register my file in HKEY_LOCALMACHINE\Software\Microsoft\VisualStudio\8.0\MSBuild\SafeImports, but the path to the file is not constant on each of my coworkers computers and it is imported from several different projects so doing a hard coded relative path is not a good idea either.
If there is a way to get the current working directory that will work too (the working directory switches with each import and I think I could save it off)
There is not a reliable means to identify the "current file". When MSBuild processes a file it can import several other files, the end result is a single in memory complete representation of the file. When the targets are executing they do not know which file they were declared in.
This is why reusable build scripts must be "parameterized" to accept the location to known relative locations. For example if you have a dependency on the location where your folder for 3rd party references are located, the build script which is driving the process must declare that property for you.
MSBuild 4.0 Only
If you are using MSBuild 4.0, i.e. Visual Studio 2010/.NET 4.0, (which can target .NET 2.0/3.0/3.5) as well. Then you now have these properties which can be used for this specific purpose:
MSBuildThisFile
MSBuildThisFileDirectory
MSBuildThisFileDirectoryNoRoot
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
In 4.0+ you can use properties like $(MSBuildThisFile) to do exactly this. See here