There used to be a way to set the path of the external program path with macros.
My teams needs the ability to set this value based on their path. When we check the project file in, it overrides local settings.
Any solutions for this?
If you are referring to the Start external program option in C# project Debug settings, you can use the following C# code that sets it for the selected startup project (you can run it with Visual Commander):
Project startupProject = DTE.Solution.Item(((DTE.Solution.SolutionBuild as SolutionBuild2).StartupProjects as object[])[0]);
Properties p = startupProject.ConfigurationManager.ActiveConfiguration.Properties;
p.Item("StartProgram").Value = #"c:\my.exe";
Related
I am keeping asking questions about VisualStudio but to be honest I do not understand a word from its documentation.
In the json files generated by the VS are placed build variables like ${workspaceRootFolderName}, ${workspaceRoot}, ${env.gccpath} etc etc but I do not know how to set it up.
If the the CMAKE project.
I have two questions:
Is it possible to set those variables from CMAKE files?
If not how can I set them up another way. At the moment project builds but VS generated launch files cannot evaluate the variables
There are target properties that can be used to set these kind of variables in a Visual Studio project. They all begin with VS_. I didn't see any that corresponded with these particular variables in this project.
The alternative seems to be to save them in a User props file and you can set property that incorporates that file into your project.
https://cmake.org/cmake/help/latest/prop_tgt/VS_USER_PROPS.html
I'm building a library in debug mode and it builds fine, but the built version of this library doesn't indicate in any way that it is built in debug mode. What I mean is that if the library is called mylib and after building it in debug mode I'm getting mylib.dll I don't really know in what mode did I built it. I'd prefer that I would have my output called mylibd.dll or mylib_d_.dll, but is this possible to specify something like it in Visual Studio 2015?
In Visual Studio you can have settings that differ per build configuration. Therefore, to achieve what you want, you would change the library names only for the Debug configuration.
In Solution Explorer, right click on the library in question, and go to Properties. Make sure the Configuration combo is set to Debug. Then, in Configuration Properties select the General group and change the Target Name setting as you like.
There are also several individual settings for the output files generated:
Linker/General/Output File
Linker/Manifest File/Manifest File
Linker/Debugging/Generate Program Database File
Linker/Advanced/Import Library
You can double check the full command line in Linker/Command Line to make sure all the filenames match your expectations.
Similarly, this can be done for static libraries as well. The appropriate configuration properties group in this case is called Librarian.
How specifically should my command line be written as to copy the output from one project into the output of another project? The list of macros that are avaliable does not list anyway of accessing OTHER project directories under the same solution:
http://msdn.microsoft.com/en-us/library/42x5kfw4(v=vs.80).aspx
Here is what I currently have:
copy "$(TargetDir)FILE_TO_MOVE.EXE" ""
What should I put in the second quote to complete this command?
NOTE: A similar question does NOT actually show you HOW to do it, which is what I am asking: Visual Studio 2008: How do I include project output as an embedded resource in another project?
It is much easier to do it the other way around, have the project that has the dependency on the file also copy the file. Which you can do in the IDE without pre/post buid event or macro trickery.
Ensure the source project is built. Right click the target project, Add Existing Item and select the file. Click the added file in the Solution Explorer window and set the properties to Build Action = Content, Copy to Output Directory = Copy if newer. And right-click the target project, Project Dependencies, tick the source project to ensure that it always gets built first.
I am assuming that yout are copying the "FILE_TO_MOVE.EXE" in the post build events of your project.
The thing about the build events in Visual Studio is that they are run just like a batch file, therefore I beileve that the easiest way to solve your problem is to use a system environment variable in your project... This way your code would be similar to the one below.
copy "$(TargetDir)FILE_TO_MOVE.EXE" "$(MyVariable)"
Note: Visual Studio doesn't let you use your environment variable like this: %MyVariable%.
I think the correct way now would be to simply add your secondary project, i.e a Windows Service, to the References of the main project.
For example if you have a main GUI project (that the solution was created with), and a second Service project added to the solution, adding it to References of the GUI project will cause the EXE and the PDB of the service to be placed in the Debug/Release folder of you main project.
I am not sure if you still need to add the Project Dependancy as Hans suggested . This is probably automatic thanks to the reference.
There a lots of environment variables in my project properties that I do not understand. Clicking on macros (Is there a list of Visual Studio environment variables?) gives me a list of their values, but I am unable to figure out where some of these are set.
For example, I am trying to figure out where the variable $(IntDir) is being set.
What file is responsible for setting these variables? How can I modify them?
These are not environment variables.
They're just macros defined by the build system that you can use for setting build properties for your project. They automatically expand to things like the target platform ($(Platform)), the path to store intermediate files for your project ($(IntDir)), and the name of your project ($(ProjectName)).
You can't change them directly, but you can change them by modifying your project's properties. The project file (created automatically by Visual Studio when you create a new project) is responsible for setting them.
You already found a link to the big list of 'em, which is helpful in explaining what they are and what they do. As the documentation says, you can use them anywhere in your project's property pages that string values are accepted. They keep you from having to hard-code paths and other information, which is exceptionally useful.
Unlike environment variables, they do not persist or have any meaning independent of your build system. Once your project has been built, they go away. They're not used during debugging or deployment.
.If you want to see actual values for a specific VS instance for both 'standard' and 'custom', see if this answer helps. (Basically, you can use Process Explorer to find that out.)
For example, is it possible to set the Output path to your app folder within Program Files?
%ProgramFiles%\MyCompany\MyApp\ does not work.
quoted by Microsoft here:
Unfortunately this is by design. We do
not support using environment
variables in the UI however you can
edit the file manually in notepad and
specify variable names as you were
trying $(varname). This workaround
will not enable you to make edits to
the property in the project properties
however.
so changing the OutputPath property in your project file to:
<OutputPath>$(ProgramFiles)\MyCompany\MyApp\</OutputPath>
will work but all it does (as you can see when you open the project again in Visual Studio and look at the project properties) is include the relative path from your solution dir to the output dir.
in visual basic 2005
the application folder is defined as my.Application.Info.DirectoryPath
that will take you to the application folder of the currently running program
otherwise folders that are kept as variables, ex my docs ; desktop; temp;program files
are in the my.Computer .FileSystem .SpecialDirectories
Do you really want to build to your Program Files directory? You should create a deployment project. Then you can use the [ProgramFiles] as well as many other macros to deploy your application anywhere you want.