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.
Related
We have a TFS 2015 build server running the new Agent in Agent Pool.
Also we have a solution with three MS SQL database projects. One of these projects has references to another two.
When I build this solution in Visual Studio 2015 on my PC, the resulting model.xml includes all views with references through [$(DBName)] variables.
However, when I run the build on TFS, all objects with external references disappear from model, thus they cannot be found in .dacpac file and as result, we cannot do a deployment.
Could someone give a hint how to solve this issue?
Log on your build agent machine, and check the output of the TFS build to see whether the structure is the same as local build. Also, try to use MSBuild command line to build the solution manually on your build agent machine to see what result will you get.
It seems you reference output assemblies from one project. Instead of referencing output assemblies, it's suggested to make a project reference or create a NuGet package.
We have a developer team and there are many projects/solutions. So there are some projects which are used in some solutions.
For example project X is used in Solution A, Solution B and Solution C..
Our team have added the project as a reference instead of dll. So if somebody has change the code and commit to TFS and another developer pull the repository, so project X has been changed and the developer has to make combile the new project X for his solution because the project X was added as a reference.
So, i know that its better to add the dll file of project X and other solutions will not be effected by project X changes.
However, we have just started to use TFS build and i think that something going wrong. We have a Relase folder that contains only buildt DLLS in TFS server and the project has reference from these DLL. But in local machine, our team uses dlls which are build of project X instead of adding directly Project X as reference. But still if project X has been changed and compiled then the build DLL will be changed and the solution has to be reviewed again.
I know its a bit complicated but my question is that How we can add reference as DLL for all team (with versioning). For example all developer's computer has C:\Development\Relases folder and we can add Folders like
Project X 1.1
Project X 1.2
and the developers directly reference dll from this folder considering versions. But for example if another developer made a new version of Project X 1.3, i want to see also new dll on C:\Development\Relases folder.
How it can be possible and is it a good solution? If not what is your advice?
PS: We have VS Ent. 20015 and Microsoft Visual Studio TFS 14.102.25423.0
Usually the solution will using the latest dll buildt by project X. You may could check in the dll in TFS as source control. Even though source control dll is not a recommend way, but this maybe the best practices to meet your situation.
Then you just need to manage the dll the same as other external dll. Detail ways you can refer the answer from Will in this question: TFS dll and references issues
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
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.
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.