i have some visual studio projects which depend on other projects, which have different configurations.
example:
Project MyProject (Configuration: Release)
References:
Project LibA (Configuration: Release_DontLink)
Project LibB (Configuration: Release
Building using Visual Studio works correctly as the Configurations to be used for the different projects are stored inside the solution file.
But when i use msbuild to build MyProject, it builds the Release configuration of LibA, which is incorrect. Since both LibA and LibB are used by numerous other Projects, i cant change those configurations, i only have control over MyProject.
Is there any way to build MyProject using MsBuild without changing the LibA and LibB projects?
Possibly related question: Configuration for ProjectReference in MSBuild, however i did not fully understand the answer, and i think it would require me to change LibA/LibB
On the solution level (i.e: MyProject.sln), open the property pages and set the Release configuration to build Release_DontLink configuration for project LibA. If you don't have control over the sln file, you should be able to create a copy of it (i.e: MyProject.Release.sln).
Then build the solution with:
msbuild MyProject.sln /p:Configuration=Release
Alternatively (not even remotely a best practice), after building MyProject build LibA while overriding its OutDir property:
msbuild LibA.csproj /p:Configuration=Release_DontLink;OutDir=..LibA\Release
I just had the same problem and found that the solution config needed to be done for all configured platforms.
Related
We have some netstandard2.0 assemblies. When compiling they are generated within the directory .\bin\Debug\netstandard2.0 (netstandard2.0 dir name is the TFN the Target Framework Name). However only .\bin\Debug is specified in Project Properties. And we'd like to generate those assemblies within .\bin\Debug to get all our assemblies with the same directory.
We developed a Post-Build event to copy back our assemblies and their json/pdb files within .\bin\Debug and then delete the dir .\bin\Debug\netstandard2.0. However this is not a good solution because the FastUpToDate tool used during incremental compilation does'nt find .\bin\Debug\netstandard2.0\ProjectName.pdb and thus our netstandard2.0 projects are always rebuilt even when they are up-to-date.
Set AppendTargetFrameworkToOutputPath to false in your projects.
<PropertyGroup>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
</PropertyGroup>
Is there a way to specify which projects in a Visual Studio Project File (.sln) are built? I want to build only certain projects based on an input to a script, but I don't want to run multiple seperate builds from different .slns, I want to have it contained in a single /build command.
Ie. if I have
Project
...a
...
EndProject
Project
...b
...
EndProject
Project
...c
...
EndProject
..
..
Is there a way to only have a subset of projects a,b,c be built depending on the /build command I use?
Yes. Create a solution configuration for each set of projects you'd like to build as a group. Make sure only those projects you actually want built have their "Build" option checked in the Configuration Manager for that solution configuration.
Pass /p:Configuration=... on the command line to MSBuild to build that configuration (and thus that set of projects).
I really want (it would be much better) to have all versions of 'Release' build configurations map into the common '..\Release' folder as it does for solution (a) below. However I do not know how to control this and right now all new build configurations are behaving link (b) below? Where the output folder name is exactly the full name of the build configuration.... sigh..... Thanks in advance for any help you might be able to provide...
I have one solution that has build configurations as this:
solution (a):
Debug
Release
Release (Static Link)
And another solution that has build configurations as this:
solution (b):
Debug
Release
Release (ver. 2.0 with install)
Release (ver. 2.0 no install)
Selecting and Rebuilding each configuration for solution (a) creates the following output folders (these are the actual folder names):
..\Debug
..\Release
Selecting and Rebuilding each configuration for solution (b) creates the following output folders (these are the actual folder names):
..\Debug
..\Release
..\Release (ver. 2.0 with install)
..\Release (ver. 2.0 no install)
You will have to set the "Output path" under the "Build" tab of the project properties for whichever configuration is not acting as you want.
You can switch between project configurations on the top of the project properties window.
I have a big C++ project and I need to do many steps in the building phase because I am building an application that is compatible with both 64 and 32, I have three projects:
proj1,Porj2,Proj3
and I need to do the following:
Exclude a cpp File from proj1 (32bit version)
Include a cpp file to proj1 (64bit version)
build proj1
build proj2
Execute output of proj2
Exclude a cpp File from proj3 (32bit version)
Include a cpp file to proj3 (64bit version)
Build proj3
Rename the exe that was built from proj3
Exclude a cpp File from proj1 (64bit version)
Include a cpp file to proj1 (32bit version)
still there are some other steps ... I was doing that manually and its frustrating, I found the I need to use MSBUILD but is it used for building native code ? and how can I perfrom these tasks ?
-Excluding and Including cpp files into projects
-Building proj
In Visual Studio 2010 and later, C++ projects use MSBuild.
Rather than excluding or including files based on the configuration, it would be simpler to use a preprocessor directive to conditionally compile the contents of the file. E.g., wrap the entire contents of the file in:
#ifdef MY_32BIT_BUILD_MACRO
// Source file contents here
#endif
And likewise with a macro for 64-bit builds. When using Visual C++, you can use the _M_IX86 and _M_X64 predefined macros to detect whether you are compiling for x86 or x64, respectively.
Alternatively, you could add a Condition property to the ClCompile item for the particular source file in the project file, and have it only included in the build when certain properties are set. I think that conditional compilation within the source file is a better option, though, unless you have complex rules that you need to use to determine whether to include a file or not.
In your solution, you can set project dependencies to ensure that one project is built before another. Right-click the solution, select Properties, and browse to Common Properties -> Project Dependencies. Dependencies can also be specified in a project file.
You can execute the output of a build by using a post-build task. Right-click the project, select Properties, and browse to Configuration Properties -> Build Events. The Post-Build event can be used to execute a command when the build has completed.
Rather than renaming an executable after build, it's easier to just have the build produce an executable with the right name. In the Project properties, under Configuration Properties -> General, the Target Name property can be used to set the name of the primary build output.
I have a shared C# project that uses assemblies which rely on native dlls in the current directory. This project is used by developers and a build server which uses msbuild to build and deploy the project with clickonce. There are environmental variables on these machines that specify these native library paths. I tried to find a way to add the dll to the project and set copy local to true, but there doesn't seem to be a way to add a file link using an environment variable.
Is it even possible to use environment variables in the visual studio IDE? If not, what is the correct/normal way to handle this? The dlls need to be found and copied to the output when developers are building and debugging the project from source control, and they need to be added to the click once Application Files when the build server does an msbuild publish.
The msbuild project can use environment variables, so you could add a "post build"
task that uses the environment to and start devenv with "devenv /useenv".
For example:
<Target Name="AfterBuild">
<Copy SourceFiles="$(DatabaseSourcePath)\NORTHWND.MDF"
DestinationFolder="$(TargetAppDataPath)" />
</Target>