Recently I released a new version of my grid package, which I thought was working fine with both 7.2.x and 7.3.x. But unfortunately it only works in some scenarios :(
Since the package is now build against Umbraco 7.3 RC1 (and thus MVC 5), installing and using the package in Umbraco 7.3 RC1 works fine.
If I install the package in an Umbraco 7.2.x installation, it works fine when just referencing classes in the package from Razor. If I however create a new class in my Umbraco project that references classes in the package, I get the following build error:
Error 65 Assembly 'Skybrud.Umbraco.GridData, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Web.Mvc, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' which has a higher version than referenced assembly 'System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' D:\Repositories\GridTestProject\GridTestProject725\assemblies\Skybrud.Umbraco.GridData.dll GridTestProject725
If I change my package to be build against MVC 4, but still using the Umbraco 7.3 RC1 assemblies, I get a similar build error, so I can't fix it that way around.
The package is build against 7.3 RC1 since I'm using some of the new logic for grid control configs that have been introduced in 7.3.x.
Is there a magic trick to make the package work with both Umbraco 7.2.x (MVC 4) and Umbraco 7.3.x (MVC 5)?
My alternative is to maintain two different versions/branches of my package - one targeting Umbraco 7.2.x and another targeting Umbraco 7.3.x. Another alternative is to require users of the package to upgrade to MVC 5 in their Umbraco 7.2.x installations. But I really would like to avoid either alternative.
If you build against new APIs in 7.3 then it will never work, regardless of the MVC version. :-) As soon as you call the functionality that does not exist in 7.2 then the application will error out as it cannot find the functionality. The only way around that is to either detect the version or use reflection to see if the functionality is available and take a different code path if it's not available.
You can build against MVC4 (as long as you don't require a specific version in VS).
It's also worth noting that in the case that you are building against the 7.3 proejct but you are not using any new features and want it compatible with older versions of Umbraco 7.x, developers would need to update their assembly redirects in their web.config in a slightly unusual way.
For example, if you are building against 7.3, then you are referencing MVC5, but then you install your package on 7.2.8 which references MVC4. You will get errors like you have seen, but there's a work around. You can assembly redirect higher versions to lower versions. Example:
This actually works... but of course as Sebastiaan mentioned, if you are using APIs from newer versions of anything and trying to deploy your package to older versions that don't have those features, then it would never work in the first place.
Creating an Umbraco package that supports both 7.2.x (MVC 4) and 7.3.x (MVC 5)
Recently I released a new version of my grid package, which I thought was working fine with both 7.2.x and 7.3.x. But unfortunately it only works in some scenarios :(
Since the package is now build against Umbraco 7.3 RC1 (and thus MVC 5), installing and using the package in Umbraco 7.3 RC1 works fine.
If I install the package in an Umbraco 7.2.x installation, it works fine when just referencing classes in the package from Razor. If I however create a new class in my Umbraco project that references classes in the package, I get the following build error:
If I change my package to be build against MVC 4, but still using the Umbraco 7.3 RC1 assemblies, I get a similar build error, so I can't fix it that way around.
The package is build against 7.3 RC1 since I'm using some of the new logic for grid control configs that have been introduced in 7.3.x.
Is there a magic trick to make the package work with both Umbraco 7.2.x (MVC 4) and Umbraco 7.3.x (MVC 5)?
My alternative is to maintain two different versions/branches of my package - one targeting Umbraco 7.2.x and another targeting Umbraco 7.3.x. Another alternative is to require users of the package to upgrade to MVC 5 in their Umbraco 7.2.x installations. But I really would like to avoid either alternative.
If you build against new APIs in 7.3 then it will never work, regardless of the MVC version. :-) As soon as you call the functionality that does not exist in 7.2 then the application will error out as it cannot find the functionality. The only way around that is to either detect the version or use reflection to see if the functionality is available and take a different code path if it's not available.
You can build against MVC4 (as long as you don't require a specific version in VS).
Thanks for the answer. I'm not sure that I understand the detect version part. Would that be something like this:
https://github.com/skybrud/Skybrud.Umbraco.GridData/blob/master/src/Skybrud.Umbraco.GridData/GridControl.cs#L84
Besides the the implementation of the
ReplaceEditorObjectFromConfigmethod, I'm not using any new methods or APIs in 7.3.I think I've already set the reference not to be to a specific version, but I'll play a bit more around with that one.
Yup, that looks about right, you're detecting the version just fine!
It's also worth noting that in the case that you are building against the 7.3 proejct but you are not using any new features and want it compatible with older versions of Umbraco 7.x, developers would need to update their assembly redirects in their web.config in a slightly unusual way.
For example, if you are building against 7.3, then you are referencing MVC5, but then you install your package on 7.2.8 which references MVC4. You will get errors like you have seen, but there's a work around. You can assembly redirect higher versions to lower versions. Example:
This actually works... but of course as Sebastiaan mentioned, if you are using APIs from newer versions of anything and trying to deploy your package to older versions that don't have those features, then it would never work in the first place.
is working on a reply...