I have inherited a visual studio 2003 project which uses some custom build steps. I'm having some trouble with the path to the tool. Where does visual studio get its PATH? I've echoed out %PATH% in the custom build step and it has no resemblance to the system path. I did find a value in the registry
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories
Path Dirs which looked like it might be the path used by visual C but chaning it doesn't seem to alter the path in VC. Any ideas?
Visual Studio has the annoying habit of 'playing' with your path, which leads to the effect you've seen.
The easiest way to work around it if you're willing to change the environment inside VS (which will change it for all your projects) would be to go to Tools > Options > Projects > VC++ Directories and add the required directories to the appropriate setting - in your case that should be 'Executable files'.
Another method I am using if I don't want to change the overall environment is to create a batch file that first calls vsvars32.bat for the appropriate compiler version, then manipulate the PATH variable and finally starts 'devenv'. I actually prefer this approach but it means your disk is littered with small batch files that you'll only use to kick off Visual Studio...
Related
We're working in quite a large project and is having a hard time getting people to configure their Visual Studio correct (tabs instead of spaces etc.). We found a great solution in using the EditorConfig extension for Visual Studio.
However there are still some developers that seems to ignore our request to install this extension to their Visual Studio and hence I'm wondering if there is any way to force an extension to be installed before a solution can be opened, maybe some setting in the .sln file?
No there is no such option built-in. If your machines are domain joined, you could push out the installer through System Center or domain logon scripts.
You could cheat and create a solution level pre-build step. Create a target file named: before.{solutionname.sln}.targets and store it next to your solution file. Check it into source control. In the targets file you can use standard MsBuild to see if the extension is installed (you'll need to check the file system probably) and if not present force the installation by calling vsixinstaller.exe to trigger the install.
In Visual Studio 2010 through 2013, by default (eg. When I create a new Console Application) new solutions output their compiled executable into Solution name/Project name/bin/Debug/. I want them to be output into Solution name/Debug/, and likewise for all other build configurations like "Release".
I can do this by manually going into properties of each project, going to the Build tab, changing Output path from bin\Debug to ..\Debug. I must repeat this for every project and every build configuration.
After dozens of solutions, I'm a bit sick of doing this tedious task by hand every time. Is there a way to change the default output path?
A solution that works for Visual Studio 2013 is sufficient.
This property is defined in each Visual Studio Project Template
So, for example, the C# Console Application template is located in
\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033\ConsoleApplication\consoleapplication.csproj
The csproj is an XML file that you can edit at your will. The build output directory is define like this (for each configuration):
...
<OutputPath>bin\Debug\</OutputPath>
...
<OutputPath>bin\Release\</OutputPath>
...
If you change this file, it will change all your future new C# Console Application projects. You could also write a utility program that list all csproj in \Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates and update them accordingly.
This is not necessary.
One of the projects in your solution is marked as the Startup project, shown in bold in the Solution Explorer window. An EXE project, like your console mode app. You used Project + Add Reference to add references to other projects in the solution so you can use the class libraries that those projects generate in your console mode app.
Those references will have the Copy Local property set to True.
When you build your project, MSBuild will automatically copy the assemblies from their respective bin\Debug directory into the bin\Debug directory of your console mode app, thanks to that Copy Local setting. And it is smart enough to also look at the dependencies of those class libraries and copy them as well.
So after the build is complete, the bin\Debug directory won't just have your console mode project's EXE file but also all the DLLs it needs to execute properly.
There are a few ways that this can go wrong and MSBuild cannot figure out that such a dependency actually exists. Pretty uncommon, you'd for example have to use Reflection in your code to load assemblies (Assembly.Load() and friends). The workaround for that is to explicitly copy the dependency in a post-build event. You didn't leave enough bread-crumbs in your question to judge whether that's the real problem.
What you ask for is certainly possible, the IDE just doesn't make it easy because it wasn't designed to assume this was necessary at all. You'd have to replace the Build + Output Path setting to, say, ..\Debug instead. You can create your own project template with that setting already preset. Create a new class library project, change the setting and use File + Export Template to create the template. You'll have it available the next time you create a project.
But, really, find out first why the default Copy Local machinery isn't working for you.
Rather than changing a global, protected file, you can create your own .targets file that changes the <OutputPath> however you want and import that into your projects. This could also set other defaults you might want to change and don't want to do for every project. All you'd have to do then in your project files is add something like toward the top (after the root element, of course):
<Import Project="$(SolutionDir)\Common.targets"/>
get from https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473
The standard setup for .NET solutions is that each assembly gets its
own bin directory to which it is copied along with the assemblies of
all its dependencies. If your solution contains an .EXE file and, say,
40 different assemblies. Does it really make sense to copy the
dependencies of each assembly to each separate build directory? The
target directory of the EXE should be enough. Another way to
accomplish roughly the same would be to give the assemblies common
output directories. That also avoids the copying. Some earlier
versions of Visual Studio did not support this well, so be careful. I
have, however, been using this approach with VS2008 for quite a while
without noticing any problems.
question - how to disable creating "bin" etc for all child projects? Thanks
Edit - there is a more comprehensive answer at Optimizing Visual Studio solution build - where to put DLL files?.
Create top level /bin/ folders above all your child projects. Then for each project, right click and go to properties. On the build tab, you can amend the "Output path" to point to your new top level bin with a relative path (e.g. ../bin/Debug or ../bin/Release). You should do this for each build configuration (e.g. Debug and Release).
This should result in each assembly being copied just once to the same location.
Note I've checked this procedure in VS2008 but I suspect it is similar in 2010.
I often build and modify databases from within Visual Studio 2010 Pro. I have VS set to prompt me after every change to save a change script, so that I have the scripting necessary to update the production DB when the time comes.
My issue with this is that the default directory for saving these files is always the 'current directory' when Visual Studio was started. That means it was originally the VS install directory, until I changed my shortcut to VS to at least pass my Visual Studio projects root directory.
But as a freelance developer working on various projects for various clients, my folder structure from there is still somewhat significant, so it's usually more than just a single folder down from there I need to go.
One solution can be to open Solutions from their Solution files directly, since that passes the solution directory as current. However, I never do this; I start VS directly and typically load recent projects from the start page.
So, does anyone know a way to change the default location that VS will offer to save database change scripts? It's not in the standard settings of VS; I imagine an add-in/extension could do something there, but I'm not aware of any which do, and I've not had enough experience working on extensions to have an idea how to do one myself.
Any help finding/creating an appropriate extension, or other hack, will be appreciated!
p.s. I really don't want to earn a Tumbleweed badge off this question! heh
EDIT: I wonder; perhaps the angle to look toward is changing the 'current directory' based on the solution loaded?
One point to note is you can use solution explorer and save database scripts without having a project loaded - which kind of suggests the path isn't project related, but fixed to devenv itself and devenv will have to be reloaded to change the path. So as you suggested, you need to open the solution file directly - but for me, that still didn't work, so I did a bit of batch scripting to make it work.
This is my solution - I've tested it and it works
Create a batch file - This is my version: Theres a lot of stuff that can be removed, but I'm sure you can tidy it up.
#ECHO OFF
REM this bit gets the directory from a parameter passed in as %1 - assuming %1 is a filename
SET PT=%~p1
ECHO %PT%
SET PRJ=%1
ECHO Project File: %PRJ%
SET HERE=%PT%
REM GO to visual studio command prompt, right-clic get properties and path of vcvarsall.bat
CALL "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
REM %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
CD %HERE%
ECHO %HERE%
START devenv.exe %PRJ%
Save the batch file.
Go to your visual Studio Solution file that you want to open - right-click the .sln and select "open with ..." navigate to the batch file - and open with that.
It does mean you have to open your projects by right-clicking on the solution file, and not by using the in-built recent-projects list.
Another possibility is to set an environment variable under windows for your project directory, (e.g. PRJ = C:\Documents and Settings\My User\My Documents\VS Projects) Then in the Save script dialog box, you can type %PRJ% to shortcut getting to your project folder.
Not exactly what you wanted - but workable.
I have a (C++) project that I originally developed under Linux using make to build it. I would like to also have it run in Windows and am using Visual Studio 2005 to build it. The problem I'm running into is that Visual Studio places all objects into the same output directory. This doesn't work for me because I have source files with the same name in different sub-directories. This means that the last object (with the common name) overwrites all previous ones and thus I get link errors for the "missing" code.
Setting the output directory (even using the Visual Studio variables like $(InputDir)) at the project level doesn't work because Visual Studio passes all of the source files to cl.exe at once (i.e. $(InputDir) is evaluated once rather than for each input file). It appears that this problem can be solved by manually setting the output directory for each file (at a minimum, for the affected files), but this is less than optimal and error-prone.
Is there a better way to solve this problem? I would even appreciate it even if someone is able to suggest a way to get Visual Studio to compile files one-at-a-time so that setting the output directory at the project level would have the desired effect.
You might consider using different project for each directory or so. Otherwise, using the exactly same filename within a certain project might seem a bit strange. (Sort of a hierarchy within the project structure; something I've never seen before anyway.)