I've recently found it very convenient to organize the many projects in my Unity game solution into "solution folders", which exist only in Visual Studio (not in the file system); if I do this, ReSharper can very neatly organize the project dependency graph for me. (It's getting very large, because ... reasons.)
The problem is, these folders get wiped out every time Unity rebuilds the project *.csproj files. I've tried playing with the file generation hook as described here, but haven't had any luck -- I'm not sure the property I'm looking for is even settable from the csproj XML.
So: Is there any way to either save the solution folders, or automatically re-create them when csproj files get refreshed?
I'd given up on solving this problem, but 6 weeks later I stumbled across the solution. For anyone with the same concern: You must install the "Visual Studio Editor" package within Unity. As of this summer, this package supports solution folders in VS!
Related
I have a peculiar problem where all but 1 of my projects are showing the Mercurial plug-ins for my solution correctly.
All the projects have been committed in my mercurial repository already.
The icons for the problematic project actually shows up correctly in another solution that includes it.
Fixes I've tried so far:
Recreate the Solution file from scratch.
Remove/Add Project again.
File compared csproj & sln files between the working and non working solutions.
I'm using Visual Studio 2015.
Has anyone come across this problem before?
It turns out I had to delete the hidden directories under the project folder that pertains to a different source control system (.svn).
It seems like the Mercurial add-on and/or Visual Studio gets confused if it sees more than 1 hidden folders under the project directory.
I've got a a fairly large project with many code files in Visual Studio 2015.
This folder contains lots of structures and classes that have no ties to the solution they're in, but need to be moved to an external solution to resolve a circular dependency issue.
Is there any way to automatically refactor a solution folder in VS to a new project? Resharper/other?
I found that while resharper is enabled, you can right click on a solution folder and select "Move" to automatically refactor a solution folder and it's contents..
I am working on two different solutions, say, Solution1 and Solution2. As these two solutions are dependent upon each other, I have to open two separate Visual Studio while developing.
It is really difficult to switch between these Visual Studio. I can't merge these two solutions into one as Solution1 is being used by other projects and all are part of Source Control.
Just wondering, can I open both solutions in the same Visual Studio IDE? I searched a lot but no luck. Any suggestions on existing VS AddIn or how to develop it would also be helpful.
Visual Studio version - 2012 Ultimate
Source Control - TFS
Create a third Solution C than includes project from both A and B: you can keep C as a local file i.e. you don't check it in version control if this can disturb the team.
Else you can open two instances of Visual Studio and switch at need: VS is smart enough to sense file system changes, but you have to be careful in saving before switching.
Does it have to be within the same IDE instance?
You could right click the VS icon in the task bar, select "Visual Studio 20__", and you will have two seperate instances of VS. You can then open separate solutions in both, without merging the two under one solution.
This will eat up far more resources, however. The previous responses are preferable.
What you are asking is impossible and extremely dysfunctional.
The supported solution would be to add all of the projects from Solution B to Solution A. Then you can open a single solution with all of your work. If you want compartmentalisation within your solution you can use solution folders.
If you can you should have a separate solution for the core components and package them as a nuget package. Both of your other solutions can then take a dependency on that single shared package.
open the solution 1 and right click and add the second solution. When you close the VS next time it will told you once to save the sln file. Do it for saving the settings in sln file.
Now everytime you will open sln1 will show you both project. It will not affect if you only move first project to pen drive or move to another computer. In case of 2nd project missing it will told you that 2nd project not found no more worries.
In case of Source Control - TFS I can't confirm how it work but their is some sollution for github (Which maybe hint anything for TFS).
The same trick can be applied but you don't need to push modified sln so this will not break anyone else's settings. If TFS store the files and code on the file system that you currently working then you can applied same trick to do applied this trick to that TFS project which is stored in your file system.
1.open solution1 in visual studio 2012 .
2.Right click on solution1 ,add existing project option.
3.select the solution2 .
4.Now solution1 and solution2 file are same project.
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.
After some use Visual Studio 2008 when opening a solution that is checked into Visual Studio Team Foundation will pop up a dialog saying:
Projects have recently been added to this solution. Do you want to get them from source control?
This happens every time the solution is loaded (even if no projects have been added). The only way I have found to remove this minor annoyance is to completely rebuild the SLN file.
Has anyone found a better/simpler way?
I had this recently after we moved a number of projects in the solution. I worked out eventually, that each project actual appears in solution file multiple times each with path information! So even though the path in the main reference of the project was correct it was wrong further down the file.
So go through the .sln file and make sure the paths in all the references of each project is correct.
For instance, the first reference for one of my projects is:
Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "ObexPushVB", "Samples\ObjectPush\ObexPushVB\ObexPushVB.vbproj", "{E3692A59-D636-48E8-9B57-7DA80A88E517}"
EndProject
In my case the path there was correctly updated. But then we have also for that project:
SccProjectUniqueName8 = Samples\\ObjectPush\\ObexPushVB\\ObexPushVB.vbproj
SccProjectTopLevelParentUniqueName8 = InTheHand.Net.Personal.sln
SccProjectName8 = Samples/ObjectPush/ObexPushVB
SccLocalPath8 = Samples\\ObjectPush\\ObexPushVB
So all of those paths needed to be updated too! After I fixed that manually all was well. (The sample there is after the fix BTW).
Hey, this actually happened to me about 4 years ago.
First, it sounds to me like someone on your team doesn't have all the updates applied to their visual studio installation. Go around and get everyone upgraded to the latest service pack for your VS version.
Once that is done, unbind the solution, fix the file, rebind it and tell everyone to do a force get latest on your TFS project.
See
http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/c2822ef1-d5a9-4039-9d3e-498892ce70b6
http://www.nivisec.com/2008/09/vsts-projects-have-recently-been-added.html
(broken link: http://technorati.com/posts/Yadz3Mj1pxHPSJLlnUs1tL1sIwU5jXa5rNBbIAnYdvs%3D)
This message will also occur if your solution has a reference to a project whose location is outside of the solution directory, but it doesn't physically exist (i.e. you hadn't checked it out before opening the solution). VSS (or TFS) will then give you that message and clicking OK will automatically get latest on the project that's missing so your solution won't have any unloaded projects in it.
EDIT:
Reading that again confuses me. Basically you get the message if your solution has a source control binding to a project that isn't inside of the folder your solution is in, and that outside project doesn't physically exist on your machine. Clicking on OK will check the project out for you.
In my case it was a reference to a test project which has been deleted.
I noticed that when I inspected all the projects in the Solution Explorer. Our team uses solution folders so it was not normally visible and because it was a test project it didn't have any impact on the application.
After removing the project from the solution the messages is no longer shown.
I'm working with Visual Studio 2013.
For me, it happened after having modified the folder's structure of my solution (I added a sub-folder for a project directly on the source code explorer). I got rid of this boring error by removing all the projects from my solution, using the solution explorer. After that, I closed Visual Studio, manually edited the .sln file and removed the whole section :
GlobalSection(TeamFoundationVersionControl) = preSolution
To finish, I just added the projects back to the solution as "Existing projects" with solution explorer. Visual Studio will recreate by itself the removed section of the .sln file.
The same error message can occur if someone adds a project, check-in edited solution file, but don't adds project directory to source control.
To cut a long story short - this error can mean that in .sln file there's reference to .csproj file, but the .csproj itself is physically missing.
In my case I renamed a(n) (unloaded) project in VS. It correctly moved the project to a new folder and no data was lost. However the solution file still pointed to the old directory which still existed but was empty (so the project could not be actually loaded).
After deleting the project from the solution (which was no problem because the folder was allready empty) the problem was solved.
Adding the project again from the new location was no problem either.
I had this problem after moving a number of unit test projects that were under source control (VSTS) into another folder. After this whenever I opened a branch I would get the "Projects have recently been added to this solution. Do you want to get them from source control?" error.
For some reason the csproj file from the trunk wasn't under source control which meant it was missing from the branched version. I find this happens sometimes after moving source controlled projects.
To fix it I opened the original source trunk, used Source Control Explorer to add the missing file(s), then merged the trunk to the branches to copy over the missing csproj file.
After this I could open the branched versions without the warning popping up.