NuGet Conversion part 2

This is a followup to the earlier post on the NuGet conversion I’ve been working on in a large and complex code base. I wanted to give an update on the next round of changes we’ve made.

The first change we put in last time to add a common package checkout location had an unforeseen side effect. There were other teams working to mass convert some old vbscript code to VB.net; they were working on the same developer virtual machine using all of the same database infrastructure as the C# portion of the system, and global NuGet config file change to set the package location also impacted them. They were able to remove it on the VMs they were working on right now, but we needed to remove that from the system in the long term. We found an interesting catch – the config command doesn’t have an option to remove a setting. We briefly considered if there was a value we could set that would be equivalent to what happened if there was no value set, but it wasn’t clear what it would be. We ended up changing the config file as xml manipulation, but it wasn’t as easy as it was to set it in the first place.

The second change was that we switched back to automatic package restore using the hierarchical NuGet config. When the team hosting our internal NuGet server said the url was changing and we needed to update our configuration. We considered updating our several hundred config files with the new url, but instead decided to use this as an opportunity to revisit the decision of how to do the NuGet restore. This time around we got buy in from various groups to change the build processes and switch to automatic package restore.

I used the suggested powershell scripts to do most of the conversion. The conversion went pretty smoothly; I had to make a couple of little tweaks to the version we used since we wanted to totally remove the .nuget folders. The overall process worked out fine. I wish we had pushed harder to do it in the first place.

We still haven’t dealt with the ILmerge problem described last time. So, we still have that open issue to deal with, before we can start using our own packages internally as the primary distribution means.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s