I am back in the .NET world in the last couple of months. This is after almost 2 years break I took from C#. ;)

A lot has changed and yet, everything is the same! Yeah, yeah, I am not working with .NET Core, but still…

The project I am working on uses the legacy Reference, not the shiny new PackageReference (more info).

The good news is we plan to migrate to PackageReference usage, but things are not so simple. The main reason is you need to migrate all projects all at once, because VisualStudio doesn’t play well with mixed usage, which is expected after many years in the Microsoft eco-system.

The bad news is upgrading 70+ projects is not a trivial task. Having “zombie” references (not used by anyone) is not helping either.

Building a fresh repo was failing

Using assemblies from other project output directories

If you got a fresh repo copy and try to build the solution - it was failing. The reason for this was some references were pointing to the bin/Debug or bin/Release directories of other projects.

Of course, from experience, if something is messed-up on one place, most likely it’s not the only one. So, I I searched throughout all the project files:

<HintPath>((?!packages).)*<\/HintPath>

This is a regex search*, which finds all HintPath tags NOT containing packages string inside them.

* Make sure to enable regex search in VisualStudio. I use VS Code when manually editing project because there is no need to unload them.

Using .NET Standard references

Now, there were cases where .NET Standard references were used when there is a full framework alternative already built. For that I used the following pattern:

<HintPath>(.*)?(netstandard)(.*)?<\/HintPath>

Note that not everything containing netstandard should be changed, but there are cases where you want to use the full framework assembly, so you don’t pull all the .NET Standard dependencies in your output dir. This is a manual process if you don’t want to reinstall a given package. ;)

We had a couple of those, note that using a wrong assembly may generate a wrong binding redirect build time (the so called - unifying), which can “magically” break your application on testing/production environments. I don’t know why this is enabled by default, but it’s something to keep on the back of your mind.

Conclusion

For now, we’ve fixed our immediate issues. It’s time consuming as each time you install a new package, you have 3 files you need to take care of:

  • project file
  • packages.config
  • app.config or web.config

Of course, there are issues with the so called binding redirect, Microsoft messed up their versioning on some of the assemblies which generates a lot of manual work every time you use NuGet through the VisualStudio interface. :(

This becomes pain in the butt when you have 70+ projects and a lot of people working, because usually you touch a lot of files when you fix any issues package/reference issues.

Good thing is NuGet is now fully integrated in VisualStudio 2017 or later. I remember using NuGet way back in the day was painful and they alleviated some of the pain, but .NET hasn’t really solved the issue with different package versions. You can check this very interesting blog post by Jon Skeet. I believe this causes a lot of weird behavior described above.

Maybe I can write something about using PackageReferences and binding redirects in another post. There is a lot to share there as well. Stay tuned! :)