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.
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
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.
I'm using MSBuild to create a deployment package as part of my build process. I am calling MSBuild with /t:package as part of the command.
This is working great except for two things.
I am using web fonts and it seems that these are not being included as part of the package (they are included in the project). How do I include these fonts?
The folder structure within the zip file is ludicrous - it includes the full path from the drive letter down. I anticipate this could cause problems with the length of path names at some point. Does anyone know how to prevent this? (I know it's a duplicate of this: Visual Studio Deployment Package - change the file structure the .zip creates?)
The reason your fonts (or any other non-standard file) are not being deployed is the "build action" is set to "none". To fix this, select the file in solution explorer and modify the build action to "content". Package your project and it will be included.
I never understood the folder structure either. By using msdeploy to publish the site it uses that folder structure to deploy multiple sites at once. It's annoying when looking at the package itself but it does "work". Also... the max file length is something like 32k characters. See: Maximum filename length in NTFS (Windows XP and Windows Vista)?
There is a way to change the internal path used within the zip:
/p:_PackageTempDir="C:\websites\myNewSite"
The switch can be used on the command line with msbuild to change the path it creates inside the zip. It is also possible to change this within VS but can't remember how off the top of my head.
We have different dev environments between developers here. When I build, I want my compiled files to be copied to a bin folder located in C:\Web\bin\. Another developer may want those files dropped in C:\Web_2011\bin\.
Using Visual Studio 2010, the way we work this now is to run a BAT file with the directories defined as parameters that need to be changed if pulling from another developer's branch.
Is it possible to store a solution-wide parameter, (in a .user or .suo file maybe,) to define where a developer wants to drop his builds?
You could do it through the project file (.vcxproj for C++ project for example).
The simplest solution would be to add a Custom Build Step that runs some batch file. This batch file could check the current user name and copy the files based on that.
(An even simpler solution would be to run a user specific batch file from his local disk)
If you really want the fully fledged solution that will allow you to save this data to the user file, you can do it by editing the project file and adding a PropertyPageSchema element that extends VS property pages with another parameter (your destination directory). You can define the Persistence attribute of DataSource element as "UserFile" and the data will be saved on your .user file. You will need to add some target that actually uses this data (copies files to the directory specified).
For more information, read about msbuild and PropertyPageSchema.
I developed an application that depends on a DLL file. When I debug my application, the applicationwould complain that:
"This application has failed to start because xxx.dll was not found."
So I have to copy the DLL file into the same directory as my .vcproj file.
Is there a way to set the project to look for the DLL file in (preferably) some relative path or (not preferred) some absolute path?
Similar concept to how we set include and library path in the project settings.
I mean when I debug my application (hitting F5) the above error would pop up.
Go to project properties (Alt+F7)
Under Debugging, look to the right
There's an Environment field.
Add your relative path there (relative to vcproj folder) i.e. ..\some-framework\lib by appending PATH=%PATH%;$(ProjectDir)\some-framework\lib or prepending to the path PATH=C:\some-framework\lib;%PATH%
Hit F5 (debug) again and it should work.
Go through project properties -> Reference Paths
Then add folder with DLL's
The search path that the loader uses when you call LoadLibrary() can be altered by using the SetDllDirectory() function. So you could just call this and add the path to your dependency before you load it.
See also DLL Search Order.
Another possibility would be to set the Working Directory under the debugging options to be the directory that has that DLL.
Edit: I was going to mention using a batch file to start Visual Studio (and set the PATH variable in the batch file). So then did a bit of searching and see that this exact same question was asked not long ago in this post. The answer suggests the batch file option as well as project settings that apparently may do the job (I did not test it).
In your Project properties(Right click on project, click on property button) ▶ Configuration Properties ▶ Build Events ▶ Post Build Events ▶ Command Line.
Edit and add one instruction to command line.
for example copy botan.dll from source path to location where is being executed the program.
copy /Y "$(SolutionDir)ProjectDirs\x64\Botan\lib\botan.dll" "$(TargetDir)"
I had the same problem and my problem had nothing to do with paths. One of my dll-s was written in c++ and it turnes out that if your visual studio doesn't know how to open a dll file it will say that it did not find it. What i did was locate which dll it did not find, than searched for that dll in my directories and opened it in a separate visual studio window. When trying to navigate through Solution explorer of that project, visual studio said that it cannot show what is inside and that i need some extra extensions, so that it can open those files. Surely enough, after installing the recomended extension (in my case something to do with c++) the
"This application has failed to start because xxx.dll was not found."
error miraculously dissapeared.
I know this question had been answered years ago, but for those like me who needed to change where the debugger starts the application, change the command property under Project Properties -> Debugging.