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.
Related
I pulled down a shared solution from GitHub;
However, I am unable to open one of the solution folders.
This folder isn't in source control (in this case: Git because of GitHub)
Git only tracks files and so not empty folders.
The folder is probably mentioned in the .csproj
Thought I would add, there is a bug where this icon appears when it shouldn't, it's probably caused by switching branches. Restarting Visual Studio seems to fix it.
I'm using Visual Studio 2015 update 3 with TFS hosted at visualstudio.com.
When I add a C# class file to one of my projects in Visual Studio, it's not automatically added to source control. For other projects in the same solution, C# class files are added automatically, as expected.
When I then add the file, manually, in the project with this problem, I get the following question;
I have to confirm to add the file to source control.
There is a similar question (Visual Studio 2015 new files not being added to source control automatically), associated with a "release" branch, which is not the case here (at least I think so - our TFS-project has never been branched)
We've never configured any .tfignore manually.
This started to happen recently and occurs on all development machines, so it's probably not a client machine issue.
I'm clueless, so any help is highly appreciated.
UPDATE
I've discovered that the problem occurs in projects with names ending with ".Lib"
Projects:
Core (ok)
Core.Lib (files not added automatically)
Communication (Ok)
Communication.Lib (files not added automatically)
I tried to add a test project Test.Lib to my solution. This project was not added to TFS either, but project Test was.
The "lib" extension is the problem. Try renaming the project folder to something else, eg. "CoreLib".
To reproduce this behavior / bug, try the following:
Create a Test directory in a directory controlled by TFS
Create a Test.Lib subdirectory in this directory.
Add a file, test.cs, to Test.Lib. (Test\Test.Lib\test.cs)
In Visual Studio's Source Control Explorer, try adding the new Test directory to source control. You'll see test.cs on the "Excluded items" tab.
The "lib" extension is used by binary files, and these are ignored by Team Explorer by default. I haven't found an official list of filetypes anywhere, but other affected file types are dll, exe, obj and possibly others. You can include these files manually by right-clicking them and selecting "Include".
So I have a handful of Visual Studio projects that I need to move to another computer. Is it as simple as a copy and paste or will that mess something up? Both machines will have the same version of Visual Studio installed, so that shouldn't be an issue.
Is there an export function that I've overlooked?
If the Visual Studio version is the same, you can just copy the project folder.
Till the time you are moving your solution file and associated files you should be good.
In case you are using any source control update your solution from there.
Hope you have the same VS version and any addon frameworks you have
You can directly copy the project to the projects folder. This worked perfectly for Visual C++ projects for me (and also some other projects). But when I copied my Cordova App from one PC to the other (Both had Visual Studio 2015), I wasn't able to open the project. Whenever I tried to open the project, trying both the ways - directly from the Project file and the open option in Visual Studio, it at first opened but when I tried to open a file, it just got hung and didn't respond.
This problem may occur because Cordova apps have some configuration files that might be different for different PCs. I am not sure that this is the reason for the problem.
A solution that I used was that I created a new Project and copied the files to the project folders (excluding the configuration files).
Can you save the file to cloud? if so then you could potentially upload the file to cloud and download the file to the new
I created a C# project and added it to source control (mercurial). I can edit files in VS, commit it and push it using TortoiseHg. It goes to the server. When some one pulls they get the files.
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
However, now someone pulled the latest code from the server - and they got the new file (it is visible through windows explorer), but when they open the solution in VS, they don't see the file.
Does someone have an idea what is wrong here? or things I should check? Thank you for the help.
P.S. I have visual studio 2010 express (so I can't use the VisualHg plugin).
Visual Studio caches changes to the solution and project until an explicit save or a build. In your comment:
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
I see that an updated .sln or .vcproj file was not mentioned and checked in. Did you see an update to either of these files via TortoiseHg? If not, make sure to build or save your project after a change like this.
Did you make sure that the Visual Studio Project File or Solution file is being updated and committed?
VS solution contains projects and each project select managed files by metadata(***.vcproj file). It's not the way include all files from root directory.
So, your co-workers can see new added files by in following two ways.
1) share project file(***.vcproj)
2) manually add files in each person's VS instance.
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.