Refactoring project referencing a nuget framework

Topics: Ecosystem, General
Jul 10, 2012 at 5:43 PM
Edited Jul 10, 2012 at 6:16 PM

Hi all, 

We're currently moving a core framework used by multiple applications to nuget. Until now, we could open up versions of solutions for these applications which include the framework projects, and use resharper to navigate through and refactor the framework from the application-specific projects. The application projects reference the binary output of the framework, but both refactoring and debugging into the framework 'just work'. 

Now, when we convert the application to nuget the framework, it's pointing to an entirely different (previous) version of the framework assemblies, so there's no way to refactor and/or debug into the framework, even with our 'WithFramework' solutions. 

We're currently exploring 2 ideas: 

1. mklink/junction the packages directory for the framework to the build location - this works for compile but not refactoring Update: this approach now works, I was symbolic linking an old version of the directory. Unless anyone else has a better option I may go with this one!

2. write an app to convert all binary references to project references & back again - this would work but seems fraught with danger.

Has anyone else tackled and solved this scenario? 

 

Jul 11, 2012 at 12:18 AM
Using a symbol server would allow developers to step into and debug the packaged DLL's without needing to do anything too complex. You wouldn't be able to refactor as easily though.

Sent from my Windows Phone

From: znite
Sent: 10/07/2012 17:44
To: Paul Stovell
Subject: Refactoring project referencing a nuget framework [nuget:362696]

From: znite

Hi all,

We're currently moving a core framework used by multiple applications to nuget. Until now, we could open up versions of solutions for these applications which include the framework projects, and use resharper to navigate through and refactor the framework from the application-specific projects. The application projects reference the binary output of the framework, but both refactoring and debugging into the framework 'just work'.

Now, when we convert the application to nuget the framework, it's pointing to an entirely different (previous) version of the framework assemblies, so there's no way to refactor and/or debug into the framework, even with our 'WithFramework' solutions.

We're currently exploring 2 ideas:

1. mklink/junction the packages directory for the framework to the build location - this works for compile but not refactoring

2. write an app to convert all binary references to project references & back again - this would work but seems fraught with danger.

Has anyone else tackled and solved this scenario?

Jul 12, 2012 at 6:06 PM

My organization is trying to figure out this problem too.  I wrote some custom MSBuild targets that copy an assembly from one project over to HintPath that other projects in the solution match. The problem is that the project build order is undefined because there isn't a Project Reference to tell MSBuild what order to build in. So you have to remember to build the framework project, then build the application project.

I also wondered about switching Reference elements to ProjectReference but haven't tried this approach yet. I can think of lots of problems with it.

Jul 26, 2012 at 7:47 PM

@znite, I spent some time coming up with a workflow that supports development across projects that are bundled as nugets and projects that consume them. My journey is documented here: http://chriseldredge.github.com/blog/2012/07/26/MSBuild-NuGet-Visual-Studio-Hackery/.

To boil it down, we're working on SlimJim, a tool that generates solution files and manipulates c# projects to allow loosely coupled projects to be loaded into a single solution easily and get built in the right order. The latest changes are in my fork at https://github.com/chriseldredge/SlimJim/.

Chris

Nov 15, 2012 at 11:26 AM

chris, sounds like you've got a comprehensive solution there :)

just a quick update from where we ended up: if you open a solution referencing both the projects referencing nuget dlls, and the projects that create those dlls - all you really need to do is change the dlls references in your shell project (ie. the windows app or SL app) to project references. This allows you do debug into those nuget projects, make changes, benefit from resharper refactoring etc. If interfaces dont change, that's all you need to do - if they do change you may need to change some of your other nuget-dll references to project references.

In general though, very simple! Once you've checked in your nuget projects & re-published, flip the project references back with a nuget update, re-test and you're good to go