Nuget not syncing packages when using app.config file instead of web.config

[timdooling]

I have an application library and I use NuGet restore to restore packages when the repository is cloned. While NuGet restores the packages, it does not sync the references in the class library with the packages in the solution. I can deal with the problem by deleting all of the references with the yellow triangles and adding them by browsing to each package in order, but I am wondering if there is a more permanent solution because this is something of an annoying problem and junior programmers have a hard time figuring it out.

Does anyone know of a permanent fix that restores the automatic operation of the nuget restore and syncing in a situation where you are using an app.config rather than a web.config file?

NOTE: The important part of this issue is that Nuget restore is behaving differently when an app.config file is present rather than a web.config file.

[emgarten]

It sounds like your packages folder moves in relation to your project or config files.

To fix project references try reinstalling the package through nuget: https://docs.nuget.org/consume/reinstalling-packages

To better control your packages folder location you may want to set the repositoryPath in your NuGet.Config file. http://docs.nuget.org/consume/nuget-config-file

[timdooling]

Not the issue. The package folder is in the right place, and the pointers in the repositories.config file are directed to it. As you know, the packages folder is located inside the solution folder.

As to your links, nothing involved in any of those links is relevant.

Also, the packages are present and loaded including the .dll. When I manually load them as references, it works just fine.

The problem this issue is addressed to is the fact that Nuget package restore is not syncing the packages with the references even though it reloads them just fine when the solution uses an app.config rather than a web.config.

[emgarten]

Restore only downloads packages to disk and extracts them, it does not modify any project files.

How does app.config vs web.config cause your references to become out of sync?

[timdooling]

Well, genius, that is the point of the issue post. I was really looking for an answer to that last question not someone to re-ask it.

[emgarten]

Some repro steps would be helpful 😄

Individual packages may modify your app.config or web.config, but NuGet does not. Packages are tracked in the packages.config file.

[timdooling]

Using nuget package console or the manage interface does not solve the inherent problem.

That gets it to work. When the repository is uploaded and then downloaded by a different user, the connections from the packages to the references are lost. This only occurs when using an app.config file. This behavior is not observed with a web.config file.

The app.config file is what is created when you create a class library. A web.config file is created for a web application.

If you re-read the issue again, the packages.config file has all the packages in it, and those packages are restored automatically to the solution folder on the first build.

The problem is that the references, which normally are automatically restored with a web application, are not being restored to point to the lib folders in the individual package folder for each package.

I believe Nuget uses the assemblyBinding entries in the web.config file to determine which packages are actually being referenced, but since an codefile with an app.config file does not have a web.config file, it concludes it doesn't have to link any of the references from the project file to the packages.

[rrelyea]

@timdooling - we're happy to engage with you and work on solutions.
Please maintain respect for our team as we work through the issue.

[rrelyea]

@timdooling - please give us repro steps, and we'll investigate options.

[timdooling]

You download the repository, rebuild the solution  (which reloads the packages listed in the packages.config file), check the references and all the references that use the  packages have yellow triangles on them.
What else do need for repro steps?

[timdooling]

I removed the app.config file entirely after determining that it was not used by a class library. I rebuilt the class library after deleting all the packages in the packages folder, and it worked fine.

Then I updated the remote repository, and setup a new repository set for the library and an application that uses it. When rebuilding the library, one of the modules loaded, but the rest of the packages did not.

I did the workaround, and it worked fine.

The issue seems to be the lack of a web.config file.

The package reload worked, but the sync did not occur for any web-related packages. The one that did was documentformat.openxml, which is not a web package.

[rrelyea]

"you download the repository" - I don't know which repository you are referring to.
Can you please give us repro steps, perhaps starting with File/New Project in VS.
Give us concrete details (step by step) on how to get into the state needed in order to see the same problems.

[timdooling]

The process I used:

1. upload a repository to bitbucket through VS 2013 interface.
2. Change settings on VS Git Settings to relocate the default repository to another location.
3. Clone the library class solution to the new repository location.
4. Perform a rebuild solution.

I am using NuGet 2.8+, so package restore should be automatic without using any of the VS legacy settings that force package restore.

Because the rebuild loaded packages that were not web-related packages, but declined to load the web-related packages, I changed the app.config file to web.config and commented out the entire contents of the web.config file.

I then uploaded the changed solution to the repository, and opened up a new clone in a different default repository.

This time the rebuild solution with the empty web.config file successfully loaded all of the packages, including the web packages, and compiled rather than generating 1000's of errors.

In a perfect world, the only thing that should control the loading of packages is the information in the packages.config file.

But Nuget package manager has an undocumented feature or bug that requires the existence of a web.config file, even if it has no contents, before it will restores packages that are web-related.

This includes Web, Net and MVC files as well as Newtonsoft.JSON, Postal.MVC5 and a host of others.

The workaround is simple, add an empty web.config file to the class library solution when it uses web application libraries.

However, because an undocumented requirement exists before Nuget will load web packages named in the packages.config file, I believe this qualifies as defect in Nuget.

Please fix it for Visual Studio 2013 users.

[yishaigalatzer]

@timdooling please provide a small repro project that illustrates your issue. NuGet does absolutely nothing with web.config or app.config during restore, and without a repro project we can't quite follow through the issue.

[timdooling]

It does nothing with the web.config file or the app.config files. I agree with you on that. Both files are inappropriate for inclusion in a class library project and neither one is created by the Visual Studio template for such a project.

I did not indicate that Nuget was doing anything with the web.config file, and in fact, the file I use has nothing in it. It merely exists in the project.

Nuget does not work with web-related packages, but does load non web-related packages, when the web.config file is not present. As soon as the empty web.config file is placed in the application, Nuget restores and links the web-related packages.

I have attached a snippet of the contents of the class library with the web.config file added.

With this setup, I can delete all the packages in the packages folder, clean the solution so that the yellow triangles appear in the references section, and the do a rebuild which reloads all the packages listed in the packages.config file. This is the expected behavior, but without the web.config file, the packages that are web-related will not load.

I don't know what else to tell you. I have tested this theory, and every time I instantiate a new repository cloned from bitbucket, I get the same results. The packages link with the empty web.config file present, they don't if you remove it.

[yishaigalatzer]

@timdooling The best way to move this forward is to create a small project that shows the issue you are referring to. Upload it to bitbucket or github, and we can look at it from there.

The term "web-related" doesn't ring any bell, and is not a NuGet concept, so I really am having trouble understanding your issue.

[timdooling]

web-related packages are:

Antlr3.Runtime, Kendo.Mvc, Microsoft.AspNet.Core, RazorEngine, Postal, Microsoft.Web.Infrastructure, Newtonsoft.Json, System.Net.Http, System.Net.Http.Formatting, WebGrease, System.Web.Razor, System.Web.Helpers, etc.

Nuget does seem to load the packages as listed in the packages.config file. That list is:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Antlr" version="3.5.0.2" targetFramework="net45" />
  <package id="DocumentFormat.OpenXml" version="2.5" targetFramework="net45" />
  <package id="KendoUICore" version="2016.1.226" targetFramework="net45" />
  <package id="Microsoft.AspNet.Identity.Core" version="2.2.1" targetFramework="net45" />
  <package id="Microsoft.AspNet.Mvc" version="5.2.3" targetFramework="net45" />
  <package id="Microsoft.AspNet.Razor" version="3.2.3" targetFramework="net45" />
  <package id="Microsoft.AspNet.Web.Optimization" version="1.1.3" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebPages" version="3.2.3" targetFramework="net45" />
  <package id="Microsoft.Web.Infrastructure" version="1.0.0.0" targetFramework="net45" />
  <package id="Newtonsoft.Json" version="8.0.3" targetFramework="net45" />
  <package id="Postal.Mvc5" version="1.2.0" targetFramework="net45" />
  <package id="RazorEngine" version="3.8.2" targetFramework="net45" />
  <package id="WebGrease" version="1.6.0" targetFramework="net45" />
</packages>

However, the packages do not seem to be linked to the references.

I am beginning to wonder since the packages are, in fact, loaded, if the problem may lie with Visual Studio at this point.

[timdooling]

The steps to create and replicate the problem are:

1. Create a new visual studio class library project with the git repository option selected. You may have to use the "Enable package restore" and check the boxes in the Options section.
2. Add postal.mvc5 to it as well as web api 2.x.. Also, add DocumentFormat.OpenXml to the project.
3. Make sure references to the binary objects in the packages are in the references section of the library project.
4. Create an upstream repository, and save the code to the repository.
5. Using the visual studio interface, point the local repository to a new repository.
6. Clone the repository you just created.
7. Do a rebuild solution on it to reload the packages.
8. DocumentFormat.OpenXml will load and be synced. The other packages will be restored by Nuget, but will probably not be synced because they are used in web applications.
9. Add an empty web.config file to the project.
10. Rebuild, and the objects that were not synced before will now be synced.
11. You can now delete the empty web.config file or leave it in because it is harmless

By "syncing", I mean in the properties window of the references section, there will be a pointer to the location of the binary file. When it is not there, the references section will display a yellow triangle for the dll.

NOTE: I changed #3 to reflect the later comment.

[yishaigalatzer]

Step 3 doesn't make any sense. Why would you do that?

Cheers,
Yishai

On Wed, Jun 29, 2016 at 8:47 AM -0700, "timdooling" <[email protected]mailto:[email protected]> wrote:

The steps to create and replicate the problem are:

1. Create a new visual studio class library project with the git repository option selected. You may have to use the "Enable package restore" and check the boxes in the Options section.
2. Add postal.mvc5 to it as well as web api 2.x.. Also, add DocumentFormat.OpenXml to the project.
3. Add references to the binary objects in the packages to the library project.
4. Create an upstream repository, and save the code to the repository.
5. Using the visual studio interface, point the local repository to a new repository.
6. Clone the repository you just created.
7. Do a rebuild solution on it to reload the packages.
8. DocumentFormat.OpenXml will load and be synced. The other packages will be restored by Nuget, but will probably not be syncedbecause they are used in web applications.
9. Add an empty web.config file to the project.
10. Rebuild, and the objects that were not synced before will now be synced.
11. You can now delete the empty web.config file or leave it in because it is harmless

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/3051#issuecomment-229399192, or mute the threadhttps://github.com/notifications/unsubscribe/ABLmt0eWVoVCMJmXgdsPPT92_E5405dIks5qQpOlgaJpZM4I_KpW.

[timdooling]

To replicate the problem. Actually, if you use package manager dialogue or the package manager console to add the .ddl's, it is probably done automatically.

The point is, references to the packages must be in the references section for the failure mode to be observed.

If you would feel better, change #3 to "Make sure references to the binary objects in the packages are in the references section of the library project."

[PatoBeltran]

Thanks for reporting this issue. We have not been able to reproduce this issue. If you are still able to reproduce this with the latest NuGet version, please provide additional steps.

[booktrakker]

I have exactly the same issue. The Versions reported in app.config are never updated, and that causes a major hassle. I can completely agree with the frustration reported by timdooling. And I can see why he got frustrated here.

This is ridiculous. I have to manually update the app.config file every time I update a nuget package, that should be automatic.

[booktrakker]

I have now pulled my hair out for a few hours trying to find a solution to this. And I can tell you that the attitude expressed by timdooling is not unwarranted. This is idiotic. The Reference entries should be updated automatically because this is a nightmare to manage manually.. It is f'ing insane.