In one of our projects, I've recently converted from the (now broken) old-school MSBuild based automatic package restore to the shiny new automatic package restore in Nuget 3.0 (Visual Studio 2015 RTM default).
As the official guidance suggests, I have created a .nuget/Nuget.config file in the solution folder to stop it from uploading the binaries. No more clutter in source control. Life is good.
However, this doesn't work on other machines if the Nuget.config isn't itself included in source control, so I have done just that. Now life is bad again.
Visual Studio can't load Nuget correctly and the error log indicates that it can't open .nuget/Nuget.config read-write. Which is fair enough, since it's under TFS source control and not checked out.
So here's the question: How to have my cake and eat it, too?
Upgrade to Nuget 3.1.1, it behaves as expected and doesn't open the file read-write.
Delicious cake.
The discussion for this (closed) issue is here: https://github.com/NuGet/Home/issues/1103.
Related
Last night, I updated Visual Studio 2015 on my system from RTM to Update 2. I now get an error message when I try to add a new View to an ASP.Net MVC application I am working on:
There was an error running the selected code generator:
'Expected 1 export(s) with contract name "NuGet.VisualStudio.IVs.PackageInstaller" but found 0 after applying applicable constraints.'
Any ideas on how to fix this? I had no trouble adding a few views to this project yesterday before I installed the update.
tl;dr - Reinstall NuGet Package Manager
I know this is an old thread. But I encounter the same error message today and found no solution online that works for me. So I decided to answer on this old thread for future devs that will encounter the same error message.
The reason for my case is that my NuGet Package Manager was missing.
I recently installed Wekan and it required me to install Visual C++ 2015 Build Tools, and I think that might be the culprit why NuGet was removed.
So, my solution is to download and reinstall NuGet Package Manager:
In Visual Studio open Extensions and Updates Tools > Extensions and Updates (or by pressing ALT+T+U)
On the left pane click Online and search for keyword NuGet Package Manager for Visual Studio 2015, download/install
Restart VS
These are the other solution that worked for some (didn't work for me):
Try clearing the ComponentModelCache, the cache will rebuild next time VS is launched.
Delete NuGet.Config at C:\Users\UserName\AppData\Roaming\NuGet, and restart VS
Unload/Reload project, Clean solution, Rebuild then restart VS
Updating the VS2015 will force you to update after that the whole work you have done so far. Most of the references specially NuGet are changed or outdated in 2015. I am currently using vs2013 with MVC5. I would suggest you to update the references and find a solution about this NuGet package. It might be no longer available for this view you want to add. In addition, there is a similar topic with Q&A to your and it is accessible right here: Unable to Install Any Package in Visual Studio 2015 . Take a look but VS2015 the free version is not that good for coding. Better download visual studio 2013 with update 5 and you will be much better. If you still want to keep it with VS2015, take a look at this and download it.
VS2015 NuGet Manager:
https://visualstudiogallery.msdn.microsoft.com/5d345edc-2e2d-4a9c-b73b-d53956dc458d
I have a project which works fine. This morning, I created a new TFS project and published all the code from Visual Studio 2015.
On another computer, also via VS2015, I've logged into Visual Studio Team Services to grab the same project and downloaded all the code
When I try to build, there are over 100 errors, but the cause appears to be the same. It can't find resources, and the error messages all appear to be
The type of namespace name 'some name' does not exist in '....' (are you missing an assembly reference?)
So, I expand the References and I'm missing pretty much all of them. In fact, other than the references within my own project, the rest are not there
Looking at the properties shows no path. Back on the original PC I see the path to any of the .dlls is similar too
C:\Users\Me\Documents\Visual Studio 2015\Projects\MyProj\ToT\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll
Is the issue that since this path doesn't match on the 'faulty' machine it can't show... Therefore what is the solution to this
I checked and noted that the files do appear to exist when I look at them in File Explorer.
All system references missing Visual Studio 2013 NuGet Async did not help
Please note, this happens with all projects in my solution, but not consitently. For example, EntityFramework is missing from all, but System is missing from my UI layer, but not from my BLL layer
Is there a way to fix this?
You need to run the update-package -reinstall command to reinstall all referenced packages.
I had the same problem, there are lots of answers by now but I will still post it here:
1.Close Visual Studio
2.Manually delete the local “packages” folder
3.Reopen the solution, and rebuild. (Nuget should restore the packages)
Source:
http://robertgreiner.com/2013/09/team-foundation-service-build-error-nuget/
Go to TOOLS -> nuget package manager -> package manager console -> and run to the console : UPDATE-PACKAGE -REINSTALL .
Clean your solution, rebuild and you are ready!
Sounds trivial but your missing references to system.xxxx could imply a problem with the .NET Framework, what version are you using and is it installed properly on your 'faulty' machine. Might be worth a re-install/repair? I'd check what versions are actually referenced too.
As for NuGet, make sure that Enable package restore is set as:
Also, I had a problem similar to this once and I had to upgrade the NuGet package manager to version 3 in Tools -> Extensions and Updates (You need to uninstall and then re-install as update won't work)
Finally if that doesn't work, check in File Explorer in the packages path and delete all packages. They should not be included in source control as this is what NuGet will download. If they are there or partially there, sometimes it will not download them.
Verify the .NET version:
Open the project properties pane and check the Target Framework:
Ensure this version of .NET is installed. OR change the target framework to a suitable version
First, go to VS--Tools--Extensions and Updates to check whether there are updates, install all updates. Then select one reference with a warning icon, check the Specific Version property, if the value is True, change it to False.
If the issue persists, check the Reference Assemblies of .Net framwork on your two computers, to see whether they are under the same location (the .Net framework is supposed to be under *C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework*).
=========================================================================
11/5: To avoid references missing, you can either check in all references to source control and reference from the source controlled ones, or use Nuget Package Manager to install packages. The previous is not recommended now, try Nuget Package Manager.
Before hitting your head against the wall with the million of Nuget 'fixes' you need to make sure you are getting ALL the DLLs that are in your Bin folder under source control. For some reason a simple "Get Latest Version" is not enough. Visual Studio will keep telling you all files are up to date but apparently this doesn't mean all the files under source control are downloaded (or it does and what happened to me is just a sassy bug). Anyways, to make sure you are truly "getting all" you need to force an update by using the "Get Specific Version" command with the "Overwrite all" option checked as VS suggests. To do this:
Go to your Bin folder in Source Control Explorer (Or w.e folder you truly want to get all)
Right Click > Advanced > Get Specific Version
Check the "Overwrite all files even if the local version matches the specified version" checkbox
Click Get
By doing this I ensured all the referenced DLLs were downloaded from TFS and for me that solved the problem. I'm using Visual Studio Enterprise 2015.
I am working through setting up our first build definition through TFS 2013. I have worked through all of the errors (mostly missing reference files) except one:
Type 'iDB2Command' is not defined.
The type is part of IBM.Data.DB2.iSeries.dll, which I have placed on the build server in the appropriate location. I am really at a loss as to what to do in this situation.
Obviously building through Visual Studio works just fine. The file is not registerable. The iSeries client/SDK installs are not necessary (I do not have them on my machine, and I can build).
My best guess is that it wants the .NET 2.0 SDK (TFS is running on Windows Server 2013 and I already had to install several versions of the Windows and .NET SDKs).
How do I get my build to see this file and complete?
Ultimately this appears to have been a permissions issue. By following advice similar to the answer to this question (which I had to do for the Excel reference), I needed to put the IBM DLL into a Libs folder within the Team Project.
Once I did this, and updated the references in the solution, the build worked just fine.
I'm working on a project in Visual studios 2013. I was trying to figure out how to do something and was recommended to look at another project on TFS that does something similar. When I got latest version of this other project, I found out it was made in VS2010. It migrated it to VS2013, and locked the file to me. I undid the changes because I don't want to modify this other program. I was unable to find a way to open that file without it trying to lock the file to me with migrating to VS2013.
As an attempted solution, I copied the file elsewhere on my computer and tried opening it without connecting to TFS. I assumed this would allow it to migrate to 2013 without updating the database. It still had issues and gave me this error: Solution file '%s' cannot be migrated because the solution cannot be checked out from source code control. To migrate the solution, make sure the solution file can be checked out and re-open it.
How can I open this solution without updating the TFS solution and locking the file to myself?
I just ran into this same problem. I checked the permissions on the solution files I was trying to open and saw that it was set to 'read-only'. I deselected read-only and the solution opened.
If everyone else is using VS2010 with Service Pack 1, then upgrading the solution isn't a problem. People will still be able to open it in VS2010 SP1, even if you check it in. See the Visual Studio 2013 Compatibility notes on MSDN for specific things to watch for.
Alternatively, after checking the files out but before opening the .sln file, create a copy of it in the same folder calling it MyProject2013.sln (for example). Add this new solution to source control using Source Control Explorer and then open it, letting Visual Studio upgrade the .sln file as it would normally. The 2010 .sln file will be left untouched and you should be OK to do what you like with the 2013 solution.
There is an ongoing project that is based on ASP NET MVC 1 and used Visual studio 2010 IDE.
I'm newly joined this project. I want to use Visual studio 2013 IDE for this prject while other developers use 2010 IDE. According to my research to achieve this goal I made some modification on csproj file. Initial and changed lines are the following:
original line:
<ProjectTypeGuids>{F85E285D-A4E0-4152-9332-AB1D724D3325};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
modified line
<ProjectTypeGuids>{E53F8FEA-EAE0-44A6-8774-FFD645390401};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
According to above changes I successfully run it on VS2013. After I checked in new csproj file on TFS, other developers couldn't open project in their IDE VS2010 as expectedly. So in a correct manner, how can I change csproj to use both VS2010 and VS2013 IDEs?
As far as I know, this is not possible.
The only way would be to refrain from checking in the project file, but then it could become tricky if you have "legitimate" modifications to check in.
The general rule is to have a standardized development platform for developers on the same project. Otherwise you end up with this kind of problem.
So basically, either upgrade everyone to VS2013 or stick to VS2010.