I have an existing project that uses several external packages that are included through the Visual Studio NuGet interface. Let's call this project Existing
In a separate project, I want to add that project as a reference. Let's call this project Separate.
I go to Separate and I right click on the Solution in Solution Explorer, and click "Add -> Existing project". This successfully adds Existing to Separate. I then right click on Existing and click build. This causes NuGet to get all of the packages.
However, after that happens all of the references are broken in Existing ... they all have the yellow triangle over them. If I look at the file system, they were successfully downloaded in to Separate\packages.
Why can't Visual Studio find the references? It installed them.
Related
I have a straightorward console application that I build using code::blocks. A client has requested a microsoft visual studio project to build it. So I downloaded and installed visual studio and created a project. Now I am trying to add my source files to the project.
Various online help pages say "Select project; select menu item "Add Existing Item" ( e.g. https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/9f4t9t92(v=vs.100). I cannot find "add existing item"! Add new item simply adds an empty file.
I tried dragging files from windows explorer onto the project, but this REMOVES the file from where it belongs - NOT what I want to happen.
Surely there must be a way to do this! Even without using alternative IDEs, different projects frequently must share common source code, so source files from one project need to be added to another.
The answer is to use File | New | Project from Existing code rather than simple 'New Project' when creating the project
I have Visual Studio 2012 solution with multiple BI projects. One of the SSIS projects do not show all the ssis packages in the Solution Explorer (checked in by another teammember). But the missing files are in the TFS (Source Control Explorer) and are visible in the physical folder.
I tried "Show all files" did not work.
I tried adding the file again but the project does not allow that saying "file with same name exists".
Any idea what is going on here
The authoritative source of what's in a project is going to be the ProjectName.dtproj file.
Inside of that will be entries for the packages that comprise the project. For a non-package deployment model, it's trivial to edit the file by hand and make your stuff show up.
It's way too much effort to do that by hand for a 2012+ project deployment model. Open the Project in Visual Studio (ssdt/bids) and right click on the project. Click Add Existing Item (not add package) and then click the "missing" package. Check your .dtproj file in and all is right with the world.
I had the same issue in 2020, I managed to solve it by building the solution.
On the menu select Build-> Build Solution OR Ctrl+Shift+B
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.
I have multiple projects in our solution that is in our TFS 2010 repository. I've added about 5 new projects to this solution in recent days.
I have found that for one of the projects, that the project file itself will not check-in to TFS. All of the artifacts contained in this project are working fine; they are checked in and I can see them in the Team Explorer. But I cannot see the project file in Team Explorer, nor is their an icon next to the project in Solution Explorer that would indicate its checked in status.
Also, clicking on any of the TFS related option in the context menu in Visual Studio results in those options being applied to the file contained in the project, not the actual project itself.
Can this be remedied or do I have to create an entirely new project and add all of the artifacts from the old project back into it?
Your project doesn't have appropriate Source Control Bindings! With the solution open, you'll need to go to File -> Source Control -> Change Source Control to view the bindings for your projects. The failing one probably will show an "Unknown" or not binded status. You can then use that dialog to correct the binding and check in the project file.
Appended Alternate Solution -
Navigate to the Team Explorer -> Source Control and manually add the files using the "Add Items to Folder" menu item.
You can try following steps
1 Unbind the project in "Change Source Control" dialog
2 Refresh project to update source control status
3 Right click the project and click Add the Project to source Control in solution explorer
I was faced with the same issue but the solution is slightly different than those mentioned so far. My project's contents were checked in but the project itself was not. The project's bindings were valid.
In the Team explorer's Source Code Explorer, the project files were greyed out. After a get-latest, TFS opened the Merge Conflicts screen where I could choose to keep the local copy.
After this, the project was part of TFS.
I have a solution in Visual Studio 2010 that is made up of 3 projects.
I have one project for my SharePoint 2010 custom timer job, one project (Project A) that is used by my custom timer job, and another project (Project B) that is used by Project A.
The problem is that when I package my project the WSP only installs the Custom Timer Job to the GAC. Is there some way to have all dependant DLLs installed as well?
You have to add those DLLs (project references) manually into the WSP project's manifest. There's a UI in Visual Studio to assist you with this, no need to modify the XML directly.
Steps:
In Solution Explorer within your WSP project locate the Package folder.
Double-click on Package.package file to open the package designer.
In the bottom of the screen click on 'Advanced'; a screen showing 'Additional Assemblies' will open.
Click on 'Add' and select 'Add assembly from Project Output'.
Choose the assembly and deployment mode (GAC or WebApplication = bin folder).
In this dialog you can also register the associated safe controls and resources. Also, via 'Add Existing Assembly' you can add assemblies available in binary form only (i.e. not available as VS projects in source code).