When I click on Build->Clean Solution in Visual Studio 2012, I'd like it to also delete several folders automatically to help with clean up solutions for archiving:
Nuget packages folder
bin and obj folders in C# project
Debug and DebugOut folders in C++ project
Is there a single location in my solution where I can specify all these folders manually? If not, what is the next simplest way to accomplish this?
Note: I found some links to add the AfterClean tag to the C# project, but it doesn't seem like the right place to put delete commands that apply to folders outside of the C# project.
I also tried the CleanProject program, but it only worked on the C# project.
Related
I'd like to share a common .targets file between different folders within the same project (using Visual Studio 2015):
MyProject
MyNupkgContent1
build
MyNupkgContent1.props
Common.targets
MyNupkgContent2
build
MyNupkgContent2.props
Common.targets <-- should be added as link
When I try to "add as linked" Common.targets to MyNupkgContent2/build, the dialog closes but does not actually add the link. Adding files as links from a different project works fine. Is it possible to link files between folders in the same project?
I'm not certain as to how you should go about linking it but depending on contents and size of application, your best bet may be simply going into your packages and manually copying + pasting them into MyNupkgContent2
Why visual studio shows folders this way ?
The first app_data shows nothing...it is totally useless but i'm afraid to delete it....
Any idea ?
You activated an option for a project to show files and folders which are within your project folder but not included in the project yet. If you activate this option you can manually add existing files/folders to the project by right clicking said files.
We have some assemblies that are not referenced by our solution directly but are required for other libraries we are using.
I noticed in VS 2010 you can add a deployable assemblies folder and that would cause the files in it to get copied to the bin while building, it seems this was removed in 2012 as all of the Microsoft stuff is available in nuget now.
What is the best way to achieve this same effect, can I just add a folder to my project and add an after build copy task to copy all of that into the bin or is there a better way to go about this.
Currently the dlls are sitting in the project root and have their build action set to content which I gather makes them get copied to the bin, however I'd like to make it a bit simpler and not have to rely on having to set things as content.
What you're doing already isn't a terrible way of handling things, to be honest, and the way we've always done so here in my day job is simply to add the assemblies into our solution as references; that does mean that they pollute Intellisense, however.
Alternatively, Phil Haack blogged that you can create a folder called _bin_deployableAssemblies and put your files in there; Visual Studio 2010 will automagically copy those into your bin folder as a part of its default build action.
This doesn't work with TFS msbuild scripts, apparently, so The Dev Stop guys blogged about how to get that to work with TFS, using a customised Target in your msbuild script.
If _bin_deployableAssemblies is no longer working in Visual Studio 2012, I would guess you could add a build action to your project file, based on the TFS build action from The Dev Stop?
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.
If I have a project called 'testing' in project A.
How can I share that folder 'testing' for project B in visual studio 2010?
The reason I would like to achieve about this is because when I change something in the folder testing of project A, I dont want to change the same things in project B.
Thanks in advance.
Maybe too late for the person who asked the question, but this is for people with similar problems. You can share folder contents with an extention 'Project Linker':
This builds upon the concept of linked files where you refer to the same file from two projects. This extention handles the management of that for an entire project. If you add a file to the project, it will be added too to the other project as a linked file. Same for deletes...
Attention: you need to have both projects in the same solution for this to work of coarse...
Extention VS2015
I used it in VS2010 and it's also availible for later versions.
You can't share folders in Visual Studio - they are logical constructs that are part of a solution or project.
The closest you can get is to add folders to the projects you need to share on and add all the files that you want to share as links. You will still need to manually synchronize all adds/deletes of files, but updates will come across all projects.
To make things easier, you may want to write a Visual Studio macro that synchronizes these folders for you (you can bind these to keyboard shortcuts and/or menu items).
If you put your solution (*.sln) files in the same directory they can share files in sub directories.