I want to add linked files to a project with a environment variable in the path.
When trying with $(SourceLoc)\File.cs, the path is rejected.
When trying with %SourceLoc%\File.cs, the path is accepted but resolved to a full path.
I can close the project and edit the project file manually, add $(SourceLoc) to the path and it work fine. But isn't there any easier way?
Update
I found out it could possibly be done with a tool window extensions and DTE. I havn't tested it yet though.
Update
I have tried doing this with extensions now but it didn't work either:
Solution2 soln;
Project prj;
soln = (Solution2)_dte.Solution;
ProjectItem prjItem;
prj = soln.Projects.Item(1);
prjItem = prj.ProjectItems.AddFromFile(#"%SourcePath%\MyClass.cs"); // fail
prjItem = prj.ProjectItems.AddFromFile(#"$(SourcePath)\MyClass.cs"); // fail
Darnit...
In Visual Studio you're adding a file to a project using standard Windows Open File Dialog, thus $(x) doesn work, and %x% is being expanded to the full path.
So no, there is no other way then edit a project file manually.
Related
I realize that similar questions were posted earlier but I need slightly different solution.
I have VS2012 C++ project A.vcxproj,that has debug1 configuration( platform x64) , and it builds corresponding .exe. It also uses a dll from other VS2012 C project B.vcxproj from a path that must be added to the environment variables. A.vcxproj.user file has following text
<LocalDebuggerEnvironment>PATH=%PATH%;C:\Program Files\libsndfile\bin;..\..\lib\simulink\;$(LocalDebuggerEnvironment) </LocalDebuggerEnvironment>
I need to add this setting automatically to the "A"project with following constraints
I cannot export user file as it as "per user", so cannot upload to our SCM system where other users can download it.
I tried adding code in main function, something like
_putenv("PATH = ....\lib\simulink");
but this does not work, as before the main file is compiled, it needs to search for the dll from specified path, which it dosn't .
Can anyone suggest a easy, portable fix , that i could distribute to all users through SCM, along with the project file.
I have also tried following:
--Created batch file setpath.bat with following content
#ECHO %PATH% set PATH = %PATH%;C:\Program Files\libsndfile\bin;C:\dev\lib\simulink
-- added to A.vcxproj settings->build event->Pre-build->Command line
call C:\setpath.bat
and I don't see the added paths under vS op window. neither does the VS User file gets the change, and running the project complains for missing dll error.
--I tried to execute the batch file in
A.vcxproj settings->
Custom build step->Execute before "Run"
and still no result.
I guess the solution needs to add needed path to current environment variable for the time VS project is "run".
Thanks
sedy
added to A.vcxproj settings-> Build Events ->Pre-Build event
call setdllpath.bat
where the file contains the following:
#ECHO %PATH%
set COMSPEC = "%VCINSTALLDIR%\vcvarsall.bat" amd64
setx PATH "C:\Program Files\libsndfile\bin;..\..\lib\simulink"
#ECHO %PATH%
So, once I build the Project, close Visual studio and open it again, and run the files wiithin project, it picks up dll correctly.
Contents in *.vcxproj.user, *.vcxproj.user or *.props use the same xml schema so can be easily exchanged or included.
First if usefull you can add UserMacros to define the path to your libraries.
Like bellow for the following two variable
PYTHONHOME=$(USERPROFILE)\AppData\Local\Programs\Python\Python37
PYTHONPATH=$(PYTHONHOME)\DLLs;$(PYTHONHOME)\Lib;$(PYTHONHOME)\Lib\site-packages
Edit the .vcxproj adding inside <Project>:
<Project .... >
...
<PropertyGroup Label="UserMacros">
<PYTHONHOME>$(USERPROFILE)\AppData\Local\Programs\Python\Python37</PYTHONHOME>
<PYTHONPATH>$(PYTHONHOME)\DLLs;$(PYTHONHOME)\Lib;$(PYTHONHOME)\Lib\site-packages;</PYTHONPATH> </PropertyGroup>
...
</Project>
After you can add inside your build configuration, the following to set the $(Path) variable.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<LocalDebuggerEnvironment>Path=$(Path);$(PYTHONHOME);$(PYTHONHOME)\DLLs;$(PYTHONHOME)\Lib;$(PYTHONHOME)\Lib\site-packages;$(PYTHONHOME)\Scripts;$(PYTHONHOME);</LocalDebuggerEnvironment>
My Visual Studio 2013 Custom Build Tool step is failing because the directory in which the step is being executed is not the directory where the project file is (which was by default the case up until recently). I can patch it by adding a cd command to the start of the step to change to the project directory but I was wondering if anyone could tell me
how this directory path is set
how to change it.
The build always assumes the project directory as 'base' directory.
This gives msbuild a set location (Builds to bin\debug is a subfolder off 'Base', reference hint paths and a lot more besides).
I would just change the execute of your tool to be reference based (i.e ....\tool.exe or similar) or make use of the path environment variables ($(OutDir),$(TargetPath),$(ProjectPath),$(TargetDir) etc).
Another option that I make use of is to have a batch file called 'post.bat' that has the necessary steps to execute a custom tool. This is then placed in the project folder and added to the project as an artefact.
Without knowing exactly where your custom tool resides relative to the project (or solution) or what the 'working directory' requirements of the custom tool are I cannot suggest more.
I'm about to start doing some benchmarking/testing of our builds, and I'd like to drive the whole thing from a command line. I am aware of DevEnv but am not convinced it can do what I want.
If I could have a single file built within a single project, I'd be happy.
Can this be done?
The magical incantation is as follows. Note that this has only been tested with VS 2010 - I have heard this is the first version of Visual Studio with this capability:
The Incantation
<msbuild> <project> <settings> <file>
Where
msbuild is a path to MSBuild.exe. Usually this should be set up for you by the VS2010 bat file so the right one will end up in your PATH, but if not I found one at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
project is the path to the vcxproj file within which your source file resides.
settings include the following:
/p:Configuration="Debug" // or whatever your Configuration is
/p:Platform=x64 // or x86
/t:ClCompile // to specify specifically you're looking to compile the file
file is actually another setting:
/p:SelectedFiles="path_to_file"
Notes
For <project> I had to specify a project (vcxproj) file instead of a solution (sln) file. The sln I would have used has multiple projects within it, so there would have been extra work to go that route anyhow (if it can even be done).
For the /p:Platform=x64 setting, there are several environment variables that pivot on what platform you are targeting (x64 v. x86) so make sure you set those up properly via Visual Studio's vcvarsall.bat.
Regarding path_to_file in the SelectedFiles parameter, this path must be the path as specified in the project file. If the path does not match the path used in the project file to reference the source, it doesn't seem to work.
We want to have our build server send the output of each build to
C:\Projects\{project name}\build\{build configuration}\.
To accomplish this, I set the Build Output path property for my projects to that in Visual Studio 2010, and build locally to make sure everything works. When I do so, visual studio changes the path to a relative one, for example ..\..\build\Debug.
Since the project directory is not the same on the build server (we use TeamCity, so the project url there is something like C:\BuildAgent\work\9358A92GF92), the output doesn't end up where we want it.
How do I make Visual Studio not change the build output paths to relative paths?
You cannot convince the IDE to make it absolute. Possible solutions:
Use a post-build event to xcopy the build output
It won't make the path relative if the output directory is on another drive. You could use the SUBST command to map a drive letter like z: to a folder on c: and fool the IDE that way
Run msbuild.exe directly on the build machine. Use the /p command line option to force the OutDir property to another value.
Solution 3 is probably best since you can make it specific to the build machine without tinkering with the project files and make the devs' lives difficult. The command should look similar to this:
msbuild /p:outdir=c:\mumble\ projectOrSolutionFileName
Beware that the output directory name must end with a trailing backslash
You can not convince IDE to use absolute path, but you can change the Project file:
<OutputPath>C:\Dir1\Dir2</OutputPath>
Your IDE will still show relative path but it will store the absolute path.
Works for me with Visual studio 2010 Sp1
On a successful build, I wish to copy the contents of the output directory to a different location under the same "base" folder. This parent folder is a relative part and can vary based on Source Control settings.
I have listed a few of the Macro values available to me ...
$(SolutionDir) = D:\GlobalDir\Version\AppName\Solution1\build
$(ProjectDir) = D:\GlobalDir\Version\AppName\Solution1\Version\ProjectA\
I want to copy the Output Dir contents to the following folder :
D:\GlobalDir\Version\AppName\Solution2\Project\Dependency
The base location "D:\GlobalDir\Version\AppName" needs to be fetched from one of the above macros. However, none of the macro values list only the parent location.
How do I extract only the base location for the post build copy command ?
Here is what you want to put in the project's Post-build event command line:
copy /Y "$(TargetDir)$(ProjectName).dll" "$(SolutionDir)lib\$(ProjectName).dll"
EDIT: Or if your target name is different than the Project Name.
copy /Y "$(TargetDir)$(TargetName).dll" "$(SolutionDir)lib\$(TargetName).dll"
If none of the TargetDir or other macros point to the right place, use the ".." directory to go backwards up the folder hierarchy.
ie. Use $(SolutionDir)\..\.. to get your base directory.
For list of all macros, see here:
http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
You could try:
$(SolutionDir)..\..\
I think this is related, but I had a problem when building directly using msbuild command line (from a batch file) vs building from within VS.
Using something like the following:
<PostBuildEvent>
MOVE /Y "$(TargetDir)something.file1" "$(ProjectDir)something.file1"
start XCOPY /Y /R "$(SolutionDir)SomeConsoleApp\bin\$(ConfigurationName)\*" "$(ProjectDir)App_Data\Consoles\SomeConsoleApp\"
</PostBuildEvent>
(note: start XCOPY rather than XCOPY used to get around a permissions issue which prevented copying)
The macro $(SolutionDir) evaluated to ..\ when executing msbuild from a batchfile, which resulted in the XCOPY command failing. It otherwise worked fine when built from within Visual Studio. Confirmed using /verbosity:diagnostic to see the evaluated output.
Using the macro $(ProjectDir)..\ instead, which amounts to the same thing, worked fine and retained the full path in both build scenarios.
Would it not make sense to use msbuild directly? If you are doing this with every build, then you can add a msbuild task at the end? If you would just like to see if you can’t find another macro value that is not showed on the Visual Studio IDE, you could switch on the msbuild options to diagnostic and that will show you all of the variables that you could use, as well as their current value.
To switch this on in visual studio, go to Tools/Options then scroll down the tree view to the section called Projects and Solutions, expand that and click on Build and Run, at the right their is a drop down that specify the build output verbosity, setting that to diagnostic, will show you what other macro values you could use.
Because I don’t quite know to what level you would like to go, and how complex you want your build to be, this might give you some idea. I have recently been doing build scripts, that even execute SQL code as part of the build. If you would like some more help or even some sample build scripts, let me know, but if it is just a small process you want to run at the end of the build, the perhaps going the full msbuild script is a bit of over kill.
Hope it helps
Rihan
I solved my problem by reinstall VS and then download .Net Core (3.x and 2.x) sdk packages
Here is my post build script
Creates the custom path for my own. Including library and version.
Copies the .dll (target file)
Copies the *.md files.
script:
md c:\_References\$(ProjectName)\$(AssemblyVersion)
xcopy $(ProjectDir)$(OutDir)$(TargetFileName) c:\_References\$(ProjectName)\$(AssemblyVersion) /y
xcopy $(ProjectDir)*.md c:\_References\$(ProjectName)\$(AssemblyVersion) /y