Home: packages.config could not be found after PackageReference migration

[chadwixk]

Details about Problem

This is with regards to migrating an existing ASP.NET solution. I did this migration on all the library projects in the solution.

Followed this guide on migrating from packages.config to PackageReference. Now getting many build errors in Visual Studio:

Could not locate C:\<my-path>\packages.config. Ensure that this project has Microsoft.Bcl.Build installed and packages.config is located next to the project file.

For each project, this error is generated once per each referenced project. Note the solution still compiles, but these errors are superfluous.

I did see this issue that seems related to this, but it is from 2016, so not a result of this PackageReference migration. And honestly, I don't fully understand how to implement the work around:

To fix this you will need to remove the dependency or reference the BCL package with exclude: build

But also thought that as this seems to be a direct result of this migration process, you may want to find a way to have the migration tool address it, if possible.

[nkolev92]

If the migration tool does not delete certain assets, it usually means that the project was modified since it was last restored.

If you do the following:

• Start with an empty project similar to the one that fails
• Install all packages that used to be installed through VS (same versions, same everything).
• Run the migrator

Can you repro the issue?

[chadwixk]

From my description, how do you know that the issue is that certain assets didn't get deleted? These were all .netframework 4.6.2 projects that I converted.
Here's some screenshots that may add some more insight. They all point to this one line in the Microsoft.Bcl.Build.targets file.

[nkolev92]

How is that targets file imported?
Microsoft.Bcl.Build.targets

If possible, can you zip up a project premigration?

Thanks

[chadwixk]

Hello @nkolev92 , unfortunately I can't upload a project prior to migration. Our software is large enterprise software that we don't want a copy of out there.

Though I'm a developer, I am very weak when it comes to things external to the code itself, like build files, references, etc. So I'm not sure what you mean by "How is the targets file imported?" This project was setup a while ago and always just worked prior to migration.

It seems that prior to the migration, the build process would use this file to determine if it should validate all the project references that exist in the packages.config file. How is the migration to packagereferences supposed to do that instead. I'm sure this migration process somehow is supposed to say, hey, don't look in packages.config any more, cause we deleted it during the migration, now go look in the project file itself..... or something like that :)

So do you know what can be done to manually fix this?

I see here that you can tell it to not validate packages....this will tell the Microsoft.Bcl.Build.targets to to skip this validation... but the worry was, don't we want reference validation? So does the migration to PackageReferences have its own way to do this? That way I can fear not about removing this validation step?

[nkolev92]

So I'm not sure what you mean by "How is the targets file imported?" This project was setup a while ago and always just worked prior to migration.

Restore/build starts with a project file (the csproj), then it processes the file line by line, anywhere it sees something like:
https://github.com/NuGet/NuGet.Client/blob/cb2efdbe978cd1206e14490e5a0ced30cfcebdad/src/NuGet.Core/NuGet.Common/NuGet.Common.csproj#L2
https://github.com/NuGet/NuGet.Client/blob/cb2efdbe978cd1206e14490e5a0ced30cfcebdad/src/NuGet.Core/NuGet.Common/NuGet.Common.csproj#L3

it effectively finds that file and replaces its content into the a unified project file. It then repeats the same exercise with every file and every import.

It seems that prior to the migration, the build process would use this file to determine if it should validate all the project references that exist in the packages.config file. How is the migration to packagereferences supposed to do that instead. I'm sure this migration process somehow is supposed to say, hey, don't look in packages.config any more, cause we deleted it during the migration, now go look in the project file itself..... or something like that :)

Yeah that's exactly the case. PackageReference solves that exact problem natively by design. The packages of the current project will become the transitive references for the transitive projects.

I see here that you can tell it to not validate packages....this will tell the Microsoft.Bcl.Build.targets to to skip this validation... but the worry was, don't we want reference validation? So does the migration to PackageReferences have its own way to do this? That way I can fear not about removing this validation step?

You don't really need the validation anymore, as I suggested above. I looked at the package on nuget.org (last published in 2014, before project.json / PackageReference), and it looks like it was just doing some stuff to workaround the limitations of packages.config.

I'd suggest just disabling the validation, and report back whether you still have issues.

Note that PackageReference has a way of disable the targets getting imported by that package too, but I don't think you'd want to do that. There's some other build logic there that might be helpful.
https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets

[Spongman]

I think i'm seeing the same issue. here's a repro:

bug.zip

[nkolev92]

@Spongman
I think the same advice applies as above.
You should disable the validation.

That's a package that pre-dates PackageReference, so if you want to continue using you need some custom steps.

Given all that, I'm closing this as not a bug, but would be happy to continue engaging with you if you have any further questions.

[ManIkWeet]

@nkolev92 It would be nice if you could give an indication on how to disable the validation. It would save future visitors a lot of time.

[nkolev92]

@ManIkWeet

The only action I can suggest is to simply delete the target definition from the project file.

[ManIkWeet]

@nkolev92 That doesn't work because it's never added when using a PackageReference.
Personally I ended up adding
<SkipValidatePackageReferences>true</SkipValidatePackageReferences>
to the project but the issue is that this disables validation for all packages so it's not ideal.

[nkolev92]

I misunderstood you question @ManIkWeet.

I didn't read my complete response in detail and I didn't recall the fact that the package bcl.build adds a custom target that gets imported.
Disabling that or removing the package altogether is a good!