I got the latest version of a Visual Studio solution on TFS. But when I try to open the solution in Visual Studio I get the following message:
Source Control
The solution you have opened is under source control but not currently configured for integrated source control in Visual Studio. Would you like to bind this solution to source control now?
Asking my colleague, I found out that he's been checking in the changes through Visual Studio without any problem.
Here's my question: Considering the fact that I can still check in my changes via IDE, what is the use of binding a Visual Studio solution or project to TFS (or more generally source control)? Except that "lock"/"red tick" icon appearing beside them in Solution Explorer.
Adding Solutions and Projects to Source Control: When you add a solution to source control, the solution becomes part of a dynamic versioning archive created and maintained by the source control provider. Each time someone checks in a new version of the solution, that version becomes part of the archive and is available to other source control users.
According to the warning message, It seems that you are opening from source control a solution that was incorrectly added to source control (it's missing some bindings strings that should have been in the sln or project files). You should click the button yes and Bind the projects correctly to their server location, then OK the dialog. The server file will be checked out and modified locally. You should checkin the changes after that.
Currently through Azure Devops, I'm setting up a .Net Desktop type with pipe-line that includes assembly libraries. In my understanding this should've work if the scenario was TFS is on-premise and I can just install any 3rd party non-nuget libraries in that server and make the build work. Right now I was able to make this work by literally copying the .dlls but I felt its more of a hack than actually letting the build know that I'm referencing assembly / non-nuget package libraries.
I'm pretty sure i've missed something, is there a way to properly set this up?
Even though it's not a recommend way, but you could check in these libraries/dlls in source control. TFS could download them from server to your build agent and refer them.
First, make sure your local build is successful and if just the TFS build is failing then it is usually due to dll reference path issue. Make sure that the Dll is referenced as a relative path in the project file (.csproj).
To add a relative reference in a separate directory, such as C:\tfs_get\Sources\assembly\abc.dll, do the following:
Add the reference in Visual Studio by right clicking the project in Solution Explorer and selecting Add Reference.
Find the *.csproj where this reference exist and open it in a text editor. Lets say your .csproj location is c:\tfs_get\sources\myfolder\myproject\myproj.csproj
Edit the < HintPath > to be equal to
..\\..\assembly\abc.dll
This build will work properly with the assumption that the folders ( assembly, myfolder) under the sources folder exist in TFS.
Update
Have a folder named "libs", or "libraries", for example, that contains all the assemblies required by your projects to compile and run.
Reference these assembly by right click the reference folder of project and browser to these assemblies files.
For build, in Source Settings (XAML, Build Agent Folder)/Repository, keep the similar structure.
More details please take a look at this similar question : How to properly check in DLLs/assemblies to TFS/Visual Studio Team Services (was VSO)
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.
We are finally getting a source control system in place at work and I've been in charge of setting it up. I've read that it's usually good practice to not include binaries in source control so I haven't. However, we have two all-purpose utility projects (each in their own solution) that generate utility .dll's which are included in almost all of our other projects (all each in their own separate solutions). We add references to the utility dll from our projects.
I would like to have our solutions set up in such a way that if the reference dll isn't built, the solution will build the dll for itself, much in the same way a make file checks for its dependencies and builds them when they're out of date or missing.
I'm new to build processes with VS so try to keep the answers simple. Any links to general build process overview tutorials would be great too. Googleing for VS references returns a bunch of how-to add references links which is not exactly what I want.
Answer: (3 step process) Add a project reference, not a binary reference by right clicking on the solution, and adding an existing project. Then under the project tab, select project dependencies and modify the project so that one project depends on another. Finally, delete any old reference to the binary and re-add the reference using the project tab in the Add references dialog box.
Where I work we typically have project references rather than binary references (as we used to a while ago). When you include a project reference, the dll will build along with the rest of your app.
The only time we go back to binary references is when we are in between Visual Studio releases (e.g. 1 project is in 2010 and everything else is in 2008. The 2010 project will have to use a binary reference for a couple of months until everyone else catches up... Project incompatibility seems to be a Visual Studio limitation that shouldn't exist).
EDIT
To add a project reference right click the solution and click Add and finally "Existing Project." Make sure that the utility projects are also under source control, and make sure that the workspaces are set up correctly or other people will not be able to open up the projects correctly!
I am working in a Web Project in Visual Studio 2008. When I hit F12 (or right-click and select Go To Definition) Visual Studio is consistently going to the Metadata file instead of going to the source.
Some Points:
All the source code is C#, there is no VB.Net
All the projects are in the same solution
Everything is a project reference as opposed to a file reference (checked and double-checked)
I have tried the Clean/Rebuild Solution approach (even to the point of clearing out the Temp directory, Temporary ASP.NET Files directory, etc).
Has anyone else seen this behavior and/or know how to fix it?
Well, another developer found the answer. The specific project we had an issue with was originally added as a file reference, then removed and added as a Project Reference. Visual Studio however, kept both in the csproj file for the web site, causing the issue. He went in and manually edited the csproj file to remove the file reference to the problem project and all is fixed now
It happens when you don't add reference as a project but point to a dll or exe using Browse tab in Add Reference dialog. If you add reference using Projects tab you should go directly to the source code when you select Go To Definition.
However, if you install ReSharper, you'll go to source code even if you added your reference to a dll/exe using Browse tab.
Looks like it needs to be setup in Resharper as well. My Visual Studio does not navigate to .NET Framework source code until I enable it in Resharper.
1. close your solution.
2. delete hidden <name of the solution>.suo file in folder where your solution's <name of the solution>.sln file exists.
3. open your solution.
4. rebuild your solution.
For those using VS 2017 (I'm at version 15.3.4 at this moment) here are the simple steps:
Open your solution in Windows Explorer and close down Visual Studio
In the explorer menu, select View and ensure that the "Hidden items" checkbox is marked
Navigate to the subfolder .vs\[your solution name]\v15
Delete the .suo file
Restart VS and build your solution
That fixed it for me: F12 opened the actual source file, not the "from metadata" version.
Visual studio often suffer from a problem of going to metadata rather than your project if you shift location where you are building the project, ie you may have several versions to test things out.
Simply delete the reference and immediately add it back and everything will be sorted out.
The marked solution does not always work. You must make sure that the referenced project GUID in the project files is the correct GUID for the project you are trying to reference. Visual Studio does allow them to get out of synch in some circumstances. You can get the project GUID from the project file with a text editor.
So if project A reference project B. Open up project B.csproj in text editor, copy out project GUID from the tag. Then open up project A.csproj in text editor, and make sure that you are using the correct GUID. Search for project name "B" in this case. It should be at . Replace the GUID in the tag with the correct one. Save and reload.
Of course also make sure file based references to your projects are removed. You only want project references.
I've kill all VS instances, deleted the SUO, launch sln and it worked for me...
Remove the reference dll, Build (will get errors), ADD THE reference (you removed) then build again ... F12 on your function should then work (worked for me).
#1
Check "View - Object Browser" and if you see more than one assembly with the same name - that's why your getting this error.
For us it was a bug in VS 2019:
If you have ASP.NET "Razor helpers" in App_Code folder the Visual Studio 2019 interprets that as a different assembly but with the same name, that hides the actual assembly.
There's no fix for that other than rewrite those helpers to partial views or HTML helpers (you will have to do that anyway if you plan migrating to .NET Core).
See this workaround on MS's site and please upvote the bug there so MS fixes it
https://developercommunity.visualstudio.com/solutions/1008795/view.html (please upvote)
#2
Another reason why same assembly can be loaded twice in the object browser is if you have a unit-test project that starts iis-express process and never kills it properly.
I figured out how to solve my problem from this post, maybe it will also work for some of you.
I followed these steps:
Close the solution.
Delete the intellisense database file for the solution: .ncb
Open the solution.
Rebuild the solution.
(I believe either step 3 or 4 regenerates the intellisense database file when it is missing)
Intellisense, "go to defintion" and "find all references" should be working again.
In my case, (using Visual Studio Professional 2015), when I had disabled the XAML designer, the F12 stopped working.
As soon as I revert the changes, and restart Visual Studio, the F12 worked again.
Checked the pattern multiple times to confirm and then posted. Hope it helps someone.
Symptom:
Visual Studio 2010 Ultimate was repeatedly failing to find references to functions, #defines, includes, etc when using the "Go To Definition" or "Go To Declaration" or "Find All References" features - oddly Intellisense was working.
Fix:
Close Visual Studio
Delete (rename if you want to be conservative) the solution .sdf file
Reopen Visual Studio
The .sdf file will automatically be rebuilt by parsing the include files in your solution
For me, the GUID solution didn't work and I couldn't find my .ncb file. (Or maybe I'm lazy and didn't look hard enough, but that's not important.) Rebuilding and restarting visual studio didn't help either.
What I did was close visual studio and delete the .dll and .pdb being referenced in the top of the Meta Data file that my intellisense kept linking to. In my case it meant I deleted my .dll and it's .pdb file from Utilities/bin/Release. (Utilities is the name of the .dll project I was having issues with.) Then I restarted visual studio and rebuilt the .dll then the whole solution. No more problems!
Just found another cause. I upgraded my web project to 4.0 but left the class libraries at 2.0. At that point all the class libraries in my solution were treated as file references from my web project. Might help someone else...
I faced the same issue and one of colleagues gave me the following solution and it worked!
If none of the above works for you,
Remove all the references and add them back (make sure the path is
correct)
Go to Solution properties, and recheck the Project
Dependencies of all projects. Make sure the project that you'll be
using is added as a dependent in the project that you are working
on.
I did all suggested steps but nothing has been changed then
finally
right click and add reference menu, project tab
simply unselected the reference project.
save the solution.
select the same project.
Rebuild the solution.
Problem sorted. Hope this will help to some one.
Below steps worked for me.
Go to .csproj file
Open it in Notepad Go to line where dll is referred.<Reference Include="">
Delete the line
<SpecificVersion>False</SpecificVersion>
or
<SpecificVersion>True</SpecificVersion>
After deleting dll files from Visual Studio first and adding them back manually from Solution Explorer --> Website --> Add --> Reference and enabling 32-bit Applications in IIS fixed it for me.
VS2017 VB.Net Windows 10 Pro - I use an assembly names "SharedCollection" which includes a VB Module named MyGlobals. One of the globals is a FileVersion. References showed metadata and the Windows Service that referenced it had an outdated setting. I had tried some of the SUO remedies above and none of them worked.
This Worked
I deleted and recreated the project reference for ShareCollection in References.
click on web site menu from VS.
Add reference...
Click on project tab from dialog box
Select ddl
Click on ok button
In my case, I had just recently changed
<mvcBuildViews>
to "true" in my site's .csproj file (to find compile errors in my Razor view files: http://forums.asp.net/t/1909113.aspx?How+to+have+Visual+Studio+2012+returned+compile+errors+on+razor+syntax+error+in+asp+net+web+page+2+ ), and when I then built I was getting errors from my within my site's /obj/Debug/ directory. From any of those files (which were out-of-date), right-clicking and selecting "Go To Definition" would give me the [metadata] version.
So for me, none of the solutions here worked, because I wasn't starting from a file that was actually in my project. Deleted that entire /obj/Debug/ directory, the errors went away, and from any normal file I can correctly use Go To Definition.
I just ran into this problem on VS 2013. Something I could (did?) not isolate was changing the GUID in the CSPROJ file. Since the CSPROJ files are checked into SVN, I could not simply change the GUID on my local dev. Instead, I was constantly SVN reverting the local change each time it happened.
First, I had to solve the changing GUID problem.
Revert the CSPROJ to the checked-in version.
Open the CSPROJ via a text editor, NOT VS.
Extract value from the pristine CSPROJ file.
{B1234567-5123-4AAE-FE43-8465767788ED}
Open the SLN file via a text editor, NOT VS.
Locate the Project reference in the solution.
Project("{FAE12345-3210-1357-B3EB-00CA4F396F7C}") = "Some.Project", "....\assemblies\Some.Project\Some.Project.csproj", "{B7654321-5321-4AAE-FE3D-ED20900088ED}"
EndProject
The first GUID listed is the Solution GUID. For every project referenced in your SLN, you should see this value repeated at the first argument. The GUID following the .csproj is the one you want to replace with the pristine GUID.
This should solve the first problem, but the "Go to Definition" landing in meta data is not solved. In our SLN file, there is a master project (our web site), so its entry in the SLN file should contain a ProjectSection entry with multiple GUID values. Here is an example:
ProjectSection(ProjectDependencies) = postProject
{AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD} = {AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD}
EndProjectSection
Notice the missing GUID in this collection is the one from my pristine project.
Add the missing GUID as the last entry between ProjectSection and EndProjectSection. The format appears to be per-line, and it is {GUID} = {GUID}.
Save the file.
Open your solution.
Right-click a reference in the newly-added project and "Go to Definition."
I had a circular reference between the two projects involved (which is a no-no). Had to restructure my code a bit in order to solve it as both projects were truly dependant on each other. Removing one of the references solved the intellisense problem. It was logically flawed and I probably wouldn't have noticed without this error!
This one worked for me:
Right click the dll in the reference folder in your solution
explorer
Remove dll file
Right click the Reference folder, then
Add reference to the dll file again
This can happen if you're trying to jump to the definition in a project that has been unloaded (Unavailable). Right-click the unloaded project and select "Reload Project".
I modified the .csproj file and in the Reference -> HinPath changed obj to bin and it solved the problem.
I had a variation of this issue, where when I loaded my solution my referencing project had errors until I compiled the project it was referencing. At that point the errors disappeared but F12 took me to metadata.
The issue was a dependency in the project being referenced that conflicted with a dependency in the referencing project. I manually removed dependencies from the project being referenced until one of them resolved the errors in the referencing project. After that I was able to F12 to the actual code, and the project would load without errors.
If anyone knows exactly why this happens I'm interested to know in the comments.
This little trick solved it for me - unload the referencing project from the solution and then just reload it
Best guess is that you don't have debug information. Maybe you have multiple copies of your assembly on disk and it doesn't have the .pdb file with it.
Do a search for your assembly names from your projects and delete them all and rebuild.