So I have a Visual Studio solution which contains 3 database (.dbproj) projects. These projects need to reference other sql projects from other solutions, which I have packaged and uploaded to nuget. How can I manage these external packages / references in Visual Studio within the dbproj's?
Right clicking the database project within visual studio doesn't give me the "Manage NuGet Packages..." option.
I can Manage NuGet Packages for Solution to at least download the required packages to the solution root but at the project level, where the references are required I'd have to manually manage the references within each projects' references and update manually any time the package is updated so the reference points to the correct versioned package directory.
Is there a better way to do this for dbproj references for database projects in Visual Studio??
I ended up following the same path, creating NuGet packages of the referenced databases and then manually (via command line) installing them at the standard \package location. Then correcting the database references manually in the IDE
There is a work item for this functionality, go vote it up. There is a fork of the functionality already developed that sounds like it is fairly feature complete. You might try it out.
Related
In my mind i have a process I want todo with TFS, but in reality I dont seem to be able to work out how todo it.
Se we have a small team of developers, we build standard components (DLLS) that we use in lots of bits of software. When we make a change to one (StandardLib) for example we can get a build to generate in TFS, but is there a way in Visual Studio of linking our references to the latest build so we always use the latest version of the DLL, without having to build it locally on our PC's
Any help is much appreciated.
You can update the build definition to create nuget packages for the dll files and publish the nuget packages to a feed. And then use nuget to manage the references in your project. When there is a new version of the dll files, you just need to run update package command to update the reference to the latest version.
I've been fiddling with the TFS2015 task based build system for a few days now. The problem I keep on running into is the following:
I am trying to use nuget packages for my external references in my projects. These exernal references are actually not 3rd party libraries but simply other (shared) libraries of our company. I'm able to restore the packages in a task, but I can't figure out how i can make the "Visual studio Build" understand where to find the restored packages. It uses the hintpath in the project file to determine the location of the external libraries to include. However, these paths (which are used locally for development) don't match the paths used on the build server. I can add a referencepath to the msbuild parameters, but this path isn't searched recursively, and the nuget package restore restores packages including the entire folder structure of the package.
My question is. Is there a proper way to make the "Visual Studio build" step understand the location of my packages without changing the hintpath in the project file. If not, what is the normal way to go here. Should I move away from nuget altogether because our references are not actually 3rd party libraries, and if so, what is the alternative way of resolving the references (without adding the binaries to source control)
My question seems to be related to Storing nuget packages in alternate location on build server, however he seems to have fixed it using a copy to the location that is specified in the hintpath of the references, which is not an option for me. It seems to me there should be an easy way I'm not seeing to be able to point msbuild to the correct location for the libraries.
After the task restoring packages, you can add task "Copy Files" to copy the packages to the location "..\packages\lib\lib.dll"
I'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008
The following references are being automatically added to my (console application) project:
Microsoft.Data.Tools.Schema.Sql.UnitTesting.dll
Microsoft.Data.Tools.Components.dll
My boss can't open the project on his machine.
As far as I know, I don't have any schema unit tests in the project, and there should be no reason for these references.
How can I resolve this? Might it be caused by the fact that I am running SSDT and my boss is not?
Update
The references can be removed via the References node in Solution Explorer, as well as via Project Properties -> References -> Unused References..., but when I next reopen the solution they are added back again.
This is a multi-project solution, but none of the other projects (WPF Application, 2 class libraries) have these added references.
Apparently this is being caused by SSDT, because when my boss installed SSDT on his machine he was then able to open the project without any problems.
Perhaps SSDT might be treating this as an SQL project, because there are a number of SQL files included in the project.
I have added reference to few dlls in my VB.net Project. When I check into Visual source safe and get latest version from another machine, VS.net 2008 throws errors.
I have to add the references again in that new machine. Is there anyway where I can keep the references in spite of files checked in to VSS?
I need to send copy all the files to production server and we don't have VS.net on the production box to add reference and build the application.
Thanks
First, be sure that the project file is checked in properly. Sometimes VS fails to regognize that the project file has changed.
A good practice is to check in all the assemblies that your project references, except the standard .NET libraries.
Another recommendation is to set up a build server, which will detect these kinds of problems early. My personal favourite is TeamCity.
For references that are not in the GAC, and if they are third party things that aren't built elsewhere inhouse, a simple approach is to add the referenced assembly as a solution item (Right click on solution node | Add Existing Item). I usually put solution items in the same folder as the sln and then add the reference to that location.
When you check in the solution solution items will go into source control with it.
Use this for small relatively simple applications. If you have more than a handful of referenced solution items follow #Petter's advice and set up a build server with associated configuration management devoted to third party dependencies etc. etc.