Is it possible to add visual studio macros to a solution, so they would be checked in by svn ?
If not, how do you deploy your utilities/scripts with your developer team ?
Unless I'm mistaken, VS Macros are stored in a .vsmacros file as selected when you created the Macro project (I think the default location is C:\Users\yourname\Documents\Visual Studio 2010\Projects\VSMacros80), so just copy that file to your project's directory and add it to the project with no build action and you should be all set.
But that's just if you want to use those macros only with that project, most macros are useful in many projects and if so I'd recommend keeping them where they are rather than in the folder of just one project, and then just add the .vsmacros file manually to subversion to some suitable location (suggestion would be a Tools folder) and check in and out manually when needed.
Related
I am building a "Solution" consisting of many small "Projects" within VS-2015.
To ensure consistency, I would like to set Project preferences such as additional include directories, additional libraries and platforms from one location or copy from one project to the next.
Could you please point me to a document that describes this?
Thanks in advance.
Since all projects are based on MsBuild, you can create a single targets file which sets the properties you want to sync across your projects. You can then import this targets file in every one of your project files.
To add a targets file you'll need to edit the csproj file directly (Unload project, edit project file in VS or through a 3rd party editor).
There are also some options like Directory.build.props and Directory.build.targets files, in Visual Studio 2017 these are automatically imported during your build and that gives you the advantage of not having to edit the project files. This may require MsBuild 15, which ships with Visual Studio 2017.
Some Visual Studio UI will be able to show the current value of certain properties, but editing them in the UI will pull these values back into to project files. This is an unfortunate behaviour of Visual Studio.
For all options to import targets files see:
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017
I needed to build my software for several different platforms using Microsoft Visual C++ 2010 and MSBuild. I added the platforms to the $(VCTargetsPath) directory and created the .props and .targets files. I then copied the files to my configuration management repository, defined a path to the parent directory for the copied files: $(CM_REPO_PATH), and wanted to redirect visual studio to use the files in the repository.
I am able to get the project to work when I create an environment variable on my machine called %MSBuildExtensionsPath% and point it to $(CM_REPO_PATH)\MSBuild. What I want, though, is to set the $(VCTargetsPath) and/or $(MSBuildExtensionsPath) within the visual studio project, not in an environment variable on every developer's machine.
When I add the property group to do this...
<PropertyGroup>
<VCTargetsPath>$(CM_REPO_PATH)\MSBuild\Microsoft.Cpp\v4.0</VCTargetsPath>
<MSBuildExtensionsPath>$(CM_REPO_PATH)\MSBuild</MSBuildExtensionsPath>
<MSBuildExtensionsPath32>$(CM_REPO_PATH)\MSBuild</MSBuildExtensionsPath32>
</PropertyGroup>
...the new platforms are not available (as if the project is still using the default $(VCTargetsPath), rather than the one specified). Is there a way to override the $(VCTargetsPath) from the project file?
Your initial statement is, that you want to build your project for a number of different platforms.
https://learn.microsoft.com/en-us/visualstudio/extensibility/visual-cpp-project-extensibility?view=vs-2017 describes in very much detail, how to achieve this in Visual Studio 2017. Hopefully the same is true for the version you are using.
The good thing about this is, you don't need to alter $(VCTargetsPath) at all.
How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".
What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.
So for example the .sln file is in:
D:\tfs\repository\main\SolutionA\solution.sln
and the dlls are in:
d:\tfs\repository\main\SolutionX\Dependencies\Binaries
What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:
1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution
4- successfully build
What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.
Some suggestions that don't involve creating pre/post build scripts are appreciated.
When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.
One work around is to...
SOLUTION SETUP
Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
Open your solution in Visual Studio (i.e. MyApplication.sln)
In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
Check-in your solution to TFS
SAMPLE FILE STRUCTURE
Main
MyApplication.sln
Source
MyProjectA
MyProjectA.csproj
MyProjectB
MyProjectB.csproj
Dependencies
Assembly1.dll
Assembly2.dll
You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:
"The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution."
Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.
Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.
Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.
In Visual Studio, if I try to copy a file from one project to another (by using Copy and Paste or by dragging the file to the new project while holding the Ctrl key) it creates a reference to the source file in the original location. Is there a way to create a physical copy of the source file and place that in the target project source direction without having to resort to using Windows Explorer to copy the file manually?
It's not pretty, but when I want to do what you're suggesting, I double-click on the file in Visual Studio, which opens it. Then I do a File->Save As, choose the right directory and save it. All from within Visual Studio. This is usually followed by adding the new file to the other project.
Was just doing this and realized I should mention a side-effect. Depending on your source control (in my case, TFS 2010), doing this from within Visual Studio may modify the location of the file in the project. For me, this means making sure that neither the file nor its project have any pending changes, doing the save as, then doing an undo of the change this causes in TFS 2010 (project change, file add and delete).
From http://msdn.microsoft.com/en-us/library/0fb6xxhb.aspx:
If you are working with solution items, Visual C++ projects, or other similar projects, you are always working with links in Solution Explorer. If you are working with Visual Basic projects, Visual C# projects, and other projects, you might be working with links or files.
Essentially, the answer to my question is 'No'. In most cases, I must use Windows Explorer.
I have a directory /media/fonts in my asp.net mvc project which contains fonts for my website. When I use the "Publish" tool in Visual Studio this folder is ignored even though it is included in my project. Other folders /media/images and /media/css are included just fine.
Is there any way to tell Visual Studio to not ignore this folder on publish?
Select your font files and Change Build action as Content from Properties Window.
You can fix this permanently by modifying the default Build Action for font file extensions (.eot, .ttf, etc)
http://blog.andreloker.de/post/2010/07/02/Visual-Studio-default-build-action-for-non-default-file-types.aspx
The link has been assassinated by the cruel march of time, so here's a copy/paste of its contents:
The default build action of a file type can be configured in the registry. However, instead of hacking the registry manually, we use a much better approach: pkgdef files (a good article about pkgdef files). In essence, pkdef are configuration files similar to .reg files that define registry keys and values that are automatically merged into the correct location in the real registry. If the pkgfile is removed, the changes are automatically undone. Thus, you can safely modify the registry without the danger of breaking anything – or at least, it’s easy to undo the damage.
Finally, here’s an example of how to change the default build action of a file type:
[$RootKey$\Projects{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}\FileExtensions.spark]
"DefaultBuildAction"="Content"
The Guid in the key refers to project type. In this case, {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} means “C# projects”. A rather comprehensive list of project type guids can be found here. Although it does not cover Visual Studio 2010 explicitly, the Guids apply to the current version as well. By the way, we can use C# as the project type here, because C# based MVC projects are in fact C# projects (and web application projects). For Visual Basic, you’d use {F184B08F-C81C-45F6-A57F-5ABD9991F28F} instead.
$RootKey$ is an abstraction of the real registry key that Visual Studio stores the configuration under:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config
(Note: Do not try to manually edit anything under this key as it can be overwritten at any time by Visual Studio).
The rest should be self explanatory: this option sets the default build action of .spark files to “Content”, so those files are included in the publishing process.
All you need to do now is to put this piece of text into a file with the extension pkgdef, put it somewhere under
%PROGRAMFILES(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\Extensions
(on 64-bit systems) or
%PROGRAMFILES(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\Extensions
(on 32-bit systems) and Visual Studio will load and apply the settings automatically the next time it starts. To undo the changes, simply remove the files.
Visual Studio does publish font files. In a special case we renamed extensions from .ttf to .jpg and they got published.