Upgrading to NO 5.1 results in missing files (and source control madness!)

Mar 4, 2013 at 10:05 PM

I've upgraded to version 5.1, which was a bit traumatic to my project and to the source control (I'm still afraid to commit the changes as many files are marked for deletion...).

The main problem was that AccountController.cs and Site.WithServices.Master were unconditionally deleted during the upgrade process. I've seen the main issues I've encountered mentioned in the project website, but without solutions. I've restored these files from the source control, but I'm not sure if this is the right solution.

Hopefully I won't run into more surprises...

Mar 6, 2013 at 10:57 AM
Edited Mar 6, 2013 at 10:59 AM
I'm sorry you've had difficulties. If you can identify more specifically what was going wrong we can try to address them.

FYI we're beginning to think about the way we handle upgrades. The problem - and the source of your issues I suspect - is that there are two aspects to each upgrade:
  1. Upgrading the various NakedObjects .dlls. This is the easy bit; NuGet does a good job of managing this, handling all the dependencies and version matching.
  2. Upgrading code files in your Mvc run project e.g. generic views, controllers, scripts and css. This is where all the problems lie because:
    a) Application developers may well have made changes to any/all those files to make their own customisations.
    b) Microsoft periodically makes minor changes to their structure/content/naming
What we're currently thinking is that in future - for upgrades, that is, not fresh installs - we should only attempt to automate the first part, and instead provide, say a separate zip of all the source code files that you need in your app (the aforementioned generic views, controllers, scripts and css) - indicate which ones have changed over the previous version - but then let people merge those code changes into their own projects by hand. A bit more work for the developer each upgrade, but less scope for frustrating failures as you've experienced.

This would mean having two separate packages, say:

NakedObjects.Mvc-FreshInstall (adds the second package, but also the generic views, controllers, scripts and css etc - into an empty Mvc4 app).

NakedObjects.Mvc (changed so that it would now install/update the .dlls only - referencing other packages such as NakedObjects.Framework as now)

Plus the aforementioned zip containing only those generic views, controllers, scripts and css etc that have changed, to be merged by hand to any existing app.

If you want to move an existing app onto the next release you only update the second package (we could put a check into the first one so that it would not work if it found any of the known Naked Objects artifacts already there).

I'd be interested in your view on this suggestion.
Mar 6, 2013 at 11:15 AM
+1 from me on this suggestion. I've always found the updating of seemingly random source files when doing an upgrade a little unnerving.
Mar 6, 2013 at 11:37 AM
Edited Mar 6, 2013 at 11:38 AM
I've seen the main issues I've encountered mentioned in the project website, but without solutions
I think ury is referring to a similar problem I ran into.

I would also prefer a manual upgrade path.
But I think it is important to have a clear indication of which files changed between versions so that I only need to give time to those.

Sadly, upgrading NOF MVC has always been one of my pain points and I don't look forward to it.

Just thinking aloud here, would it not be possible to put the NOF controllers in a separate assembly and just reference and register them from the MVC project?
I might be wrong, but I think I remember reading somewhere that even the views can be embedded in an assembly. Then our MVC projects would only contain our custom views and controllers.
obviously, we would still need templates of the generic views to base our custom views on.

Just some thoughts.
Mar 6, 2013 at 11:43 AM
"Just thinking aloud here, would it not be possible to put the NOF controllers in a separate assembly and just reference and register them from the MVC project?"

Only problem with this is that some app developers do want to be able to intercept the controller methods. And certainly people want to be able to modify the generic views.
Mar 6, 2013 at 11:49 AM
Edited Mar 6, 2013 at 11:49 AM
subclassing controllers?
Pasting in generic view templates? Or custom generic views?
Mar 9, 2013 at 7:56 AM
My two cents regarding the 2nd part of the upgrade - the manual part: while we change what we must change in the NO project files, we usually don't even want to know about the other source files (I'm exaggerating, of course). I think it would be best if when upgrading the project, you could perform a diff and silently modify the files which haven't changed, while for the developer-modified files do the following:
  • Add remarks which won't compile (kind of like svn conflict comments) in the files which should be updated. A single comment at the top of the file would do the trick.
  • Put the upgraded files (without the developer's changes) under the original files location - say in a .no-upgrade folder, and refer the developer to manually merge the changed.
  • Alternatively, upgrade all the NO files, but keep the old modified files in a folder under the original location.
Mar 9, 2013 at 10:45 AM
Some good ideas.
Mar 9, 2013 at 12:00 PM
All getting too complicated, I fear - we'll end up with a hybrid solution that doesn't make anyone happy. As of next release, we'll be going with my proposal: .dlls will be upgraded, other files will not - but versions of only those that have changed (typically only a few at most) will be in a .zip, with instructions.

(Note: Ury said that we could diff to see which files the developer had changed. Nuget already does that automatically).
Mar 9, 2013 at 1:48 PM
It does, by AFAIK it doesn't offer any merging solution, does it?