Scenario
Computer A and Computer B are on the same solution with an empty project.
Computer A install Package p.1.0 and commit changes (with packages.config)
Computer B get lastest and perform a package restore => both computers have Package p1.0
Computer A do some changes in the project and before commiting, do an Update-Package. Package p.1.0 updates to Package p.1.1
Computer A commit changes with packages.config
Computer B is also working and before committing get latest code => packages.config is updated with line Package p.1.1
Problem
Computer A have Package p1.1 installed. Computer B have Package p1.0 installed and with an Update-Package, nothing changes.
Questions
Am I wrong ?
If not, how to correct this problem ?
"Do an Update-Package before getting code from VCS resolve the problem but it's not a good solution because everyone can forget.
When computer B get latest code, there will be reference to 1.1 in packages.config and project files. This package will be installed before next build (if you didn't disabled automatic packages restore). So in this case there are no problems.
Problem could be if Computer B applied changes incompatible with 1.1 version. In this case it will be nice practice run unit tests/test app after merge before push. And continuous integration practice could be very helpful in this case.
Related
I wonder is there a way to make VS 2019 work with nuget repositories?
Usually it works fine, but sometimes occurs the following.
I pushed a package into my nexus enterprise repository, waited a while (package is already in repo), than opened a .csproj file and entered pushed version. VS cannot load a package with error
Failed to retrieve information about '%packagename' from remote
source
'https://nexus****/repository/nuget-group/FindPackagesById()?id='%packagename'&semVerLevel=2.0.0'.
Of course, if a copy the link to browser, it opens ok. I do have access to both nexus and nuget.org, but VS cannot get any package from them - neither through .csproj nor Nuget Manager UI is VS!
Restart machine doesn't matters. dotnet restore also produces the error.
The only thing helpful is to install VS update through the VS Installer.
Today I already installed an update, so I can't do this now.
Is there any way to make this work?
You could try to use nuget.exe to register the source in your machine.
nuget.exe sources Add -Name "source" -Source {Path to the package(s) source}
Then re-start your visual studio.
I looked at Package Manager Output and saw that sometimes a message appeared. The message was someting like 'cannot connect to host because it reject or already has a connection error at xxx.xxx.xxx.xxx'. (My dirty translate from Russian)
But the point is: this IP is neither nexus host nor any intermediate host. I found that is was our old enterprise proxy (because the new one had no access to nuget.org), which is obsolete and unsupported. So, I just deleted proxy section from %APPDATA%/Roaming/Nuget/Nuget.config and at least local nexus became always available for me.
I have an ASP.NET MVC 4 application. I used NuGet to update all of the NuGet packages that were installed when I created the application. One of the packages was Microsoft.Bcl.Build.
After updating these, NuGet displayed the following message at the bottom of its window:
I have since restarted Visual Studio several times, but the message still exists. When I checked the installed packages, it did appear that the updated version (1.0.8) of the package was present.
How can I fix this?
Instead of deleting all of ~/packages, see if there are any *.deleteme files in ~/packages and delete them. Then restart Visual Studio.
I believe this problem is caused by the packages being read-only or otherwise inaccessible at the file system level.
Packages under source control
Temporary work-around (untested)
Check out the entire packages folder prior to telling NuGet to restart Visual Studio to delete the packages.
Permanent work-around
I found that this could be permanently resolved by removing the packages from source control and instead using NuGet Package Restore.
Packages not under source control
Temporary Work-Around
I worked around this by deleting from the solution's packages folder all of the files that referenced the package in question. Specifically, these were:
Folder: Microsoft.Bcl.Build.1.0.7
File: Microsoft.Bcl.Build.1.0.7.deleteme
In my case, the relevant package folders remained in ~\packages, although they were empty. I deleted the folders and restarted Visual Studio, and this warning went away.
I've just deleted the folders of each package that had error in the Packages folder in my solution folder and also deleted the .deleteme files and everything works fine!
1) Delete the entire ~\packagesfolder.
2) Restart VS.
3) Go to Manage NuGet Packages and Restore
I'll agree that this can happen when your packages folder is under source control. If you like to have it there, instead of removing the bindings you can check it all out, remove the package with the NuGet Package Manager, and then check in after wards.
In my experience, I found my answer on this thread, but using a combination of a couple of different answers above so I thought I would share what I found.
I had the exact same issue with "Microsoft.Bcl.Build" as the original poster. I had been trying to update references for other functionality using NuGet and had issues with some of the updates (compatibility then rollbacks). After this NuGet failure, I started getting this error.
I initially used the selected answer and Jedidja's answer and was able to get this to work, but it only partially solved my problem. It did fix the VS restart error, but it caused a downstream issue with TFS as I could no longer check in the project as it was expecting that "*.deleteme" file. This got me thinking, so I did some testing. When I restored the file from recycle bin, I started getting the restart error again.
Here is where I deviated from the posted answers and got my full resolution to my version of the problem.
When I checked into TFS this time, the project checked everything in (after I got the projects all updated using NuGet while the "*.deleteme" file was deleted). Once it checked everything in, I noticed that file was still pending check-in so I checked the solution in again and TFS accepted that file, but it was as a deletion....assuming it checked in the first time and then VS auto deleted it which required the second check-in. Anyway....after the last pending change check-in, the file was gone and VS no longer complained about needing to be restarted. I can't say for sure because the problem is gone, but I get the feeling if I had checked the code in before deleting the file in the first place it might have solved the problem without manual file manipulation.
** Hi, everybody.**
i resolve this problem this ways.
If you have source control run the vs as administrator ( it is important )
in the solution packages -> delete thing about packages.
sample -> i deleted all entity framework version folders.
restart the vs
open solution and solution right click -> manage nuget packages for this solution.
you will see restore button :) restore
that is all.
If you are using Entity Framework 6, then you can install the NuGet package "EntityFramework.SqlServerCompact".
This enabled me to use the standard ASP.NET Identity tooling that comes with the project templates for 2013 and MVC5.
Is there a way to add a package to a project when this package is already added to another project? I would like to avoid depending on the net because sometimes we are require to work in a non connected scenario.
I know I can simple add a reference and browse, but I suspect I will loose the ability to update automatically the reference in the future.
One way to be able to work with NuGet in a non-connected state, is to supply an alternative package source, either locally on your own computer, or on a machine on your internal network. You can add new package sources in Visual Studio through Tools > Options > Package Manager > Package Sources.
We do this ourselves for two reasons:
With a local package source you can work without an internet connection.
With a local package source and the official NuGet package source disabled, we have better control of which packages are available. This way will we for instance avoid undesired updates in our development group until we've approved them.
I want to create a NuGet package from a machine that is on the office intranet, but blocks all connections to the internet.
Both NuGetPackageExplorer.application and NuGet.exe will show the exception that "No connection could be made because the target machine actively refused it".
Installing packages works fine as we have a local network folder with the .nupkg packages we use.
Is there a tool I can use to create a NuGet package on that machine?
Update:
I created a issue on codeplex for this: https://nuget.codeplex.com/workitem/3196
What I ended up doing is downloading the source code from CodePlex, going into the CommandLine project, deleting UpdateCommand.cs, and rebuilding the project. I then grabbing the exe which I renamed NuGetOffline.exe and put it along with NuGet.Core.dll to somewhere in the Path.
Update
The download page for NuGet does not have the current version of NuGet.exe. As of writing this, none of the three downloads on the page work offline and the Other Downloads have several version of Nuget.Tools, but not the current version of NuGet.exe. Go here instead for nuget.exe. Use that instead of that custom build.
The Package Explorer link on the download page is just the ClickOnce installer which does work offline. You need to find the local executable here.
I haven't been able to get "Enable NuGet Package Restore" to work on the intranet. This closed work item describes the problem. The last comment says that "2.0 should no longer run into this issue", but I am using NuGet Package Manager 2.2.400116.9051.
My aim is to have package restore working on a build server so that I don't have to check in binaries. At the moment, I'm simply trying to get it to work on my own machine using Visual Studio.
Here's what I've done so far:
Followed the instructions here http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages, including both setting the Tools-Options flag and the environment variable (belt and braces)
Installed the NuGetEnablePackageRestore package as suggested here NuGet package restore consent without NuGet
Checked everything in (the .nuget solution folder and its contents), but not the binaries I want to reference, because that's the whole point of the exercise
Here's what I'm doing:
Check out solution
Verify that nunit.framework.dll and moq.dll are not present in the checked out solution
Build the solution
Visual Studio complains that Moq is missing. I search for the dlls in the solution directory and find that:
nunit.framework.dll is present in the appropriate bin folders
Moq.dll is nowhere to be found
But there's more. This is truly mysterious, but if I do a fresh checkout, disconnect from the internet and build, I get precisely the same results - nunit.framework.dll is there, but moq.dll is not. The build process has conjured nunit.framework.dll literally from nowhere.
So it's something of an understatement to say that I am completely baffled. Can anyone suggest answers to the following questions:
Why is package restore not downloading Moq?
Where on earth is the build process getting nunit.framework.dll, if not the internet?
In vs, Options, Package Manager... there's a section "Package Cache", if you click on the "Browse" button it will take you to the location of the nuget cache in your machine.
Okay, I noticed in the documentation that enabling package restore was supposed to modify project files in order to add a new target. My project files did not have this change. Right-clicking the solution title in VS and selecting 'Manage NuGet packages...' then added the required changes and everything built as it should.
I checked, and package restore still appears to work when I have no internet access, so I'm still mystified about that. Does NuGet maintain some kind of cache of binaries outside the solution?