Publisher policy, redirection cross major/minor version, and using the latest version

re: Publisher policy, redirection cross major/minor version, and using the latest version

Xavier Musy — Thu, 14 Jul 2005 08:11:50 GMT

Ok, so let’s say I have MyApp.exe version 1.0 which consumes and exposes an SDK MyAppSDK.dll 1.0.0.0. And, because this SDK is meant to be shared and used by third-party applications, it is installed in the GAC. Now MyApp.exe version 2.0 is released, along with MyAppSDK.dll 2.0.0.0, which *is* backwards compatible with 1.0.0.0 (let’s say it has defect fixes and new functionality exposed, but is backwards compatible). Why is it then not recommended to use a publisher policy files to redirect any application which was built against MyAppSDK.dll 1.0.0.0 to the latest version? Isn’t the alternative to have each one of those third party applications to have to update their configuration file to redirect to the latest MyAppSDK.dll otherwise (or worse Machine.config)? How is that better, especially given those apps don’t have control over when MyAppSDK.dll is updated, nor would want to re-deploy configuration files for their apps each time?

re: Publisher policy, redirection cross major/minor version, and using the latest version

junfeng — Fri, 15 Jul 2005 01:36:23 GMT

If 3rd party apps work happiliy with MyAppSDK 1.0.0.0, why do you want to bring them up to 2.0.0.0?

Do you know how many apps are using your assembly? Are you really confident that your seem innocent changes won't cause any problem for all the 3rd party applications?

If you are so confident, there is really nothing stopping you from doing so.

re: Publisher policy, redirection cross major/minor version, and using the latest version

Xavier Musy — Fri, 15 Jul 2005 05:24:36 GMT

I think 3rd party apps working happily is a relative term, as some could be working acceptably with defects in MyAppSDK, and the primary reason for forcing 3rd party apps to upgrade to the latest MyAppSDK would be to take advantage of defect fixes in the latest MyAppSDK. E.g., SDK feature X works with acceptable defects in v1, which now works better with no/less defects in v2. Though arguably the case can be made that 3rd parties could potentially be relying on defective behavior Y in a previous version which is no longer there in the latest. But that can be circumvented individually in the 3rd party application config file by not allowing the publisher policy redirect, correct? Question is, which is better/worse, updating all with the possibility of breaking some with the benefit of helping some/all, or updating none and forcing any to decide & redeploy?

I think what I'm looking for is the prescribed way of doing it. Is the recommended approach to always keep every version of MyAppSDK in the GAC, and have the third party applications make the decision whether or not to upgrade via re-deployment of their configuration files? Or is SDK compatibility confidence the deciding factor on which approach to take?

Many thanks in advance!

re: Publisher policy, redirection cross major/minor version, and using the latest version

junfeng — Fri, 15 Jul 2005 11:57:42 GMT

We are going through AppCompat sweep now. There are so many seemly innocent changes that causes apps to break, partially due to our stupidity in lack of documentation, guideline and incorrect samples, partially due to developers' errors.

As for the scenario you are looking for, the recommendation is to keep the versions you supported, and have apps to decide to float or not by app.config, and only use publisher policy for servicing.

This begs for the question that how many old versions do you need to keep. It is really up to your support policy.

For certain people, they are only willing to support the lastest version. If this is the case, you can issue publisher policy to redirect to the latest version, but you will have to eat the appcompat pill as well.

Versioning is a complex issue that I don't think we have done a good job. The focus today is more on the SideBySide aspect. The other aspect of one-and-only-one is more or less ignored. I hope we will address this problem in the future.

Thanks for listening to my rant.

re: Publisher policy, redirection cross major/minor version, and using the latest version

Xiangyan — Thu, 21 Jul 2005 23:47:51 GMT

When we build the assembly, can we spedify the major version to be an earlier version and force it usable to earlier version framework? Say, we have an assembly built with 1.1 shipped, we want to use 2.0 to build the same assembly which could be used by both 1.1 and 2.0. Is that possible?
Thanks.

re: Publisher policy, redirection cross major/minor version, and using the latest version

junfeng — Thu, 21 Jul 2005 23:54:11 GMT

You have to build it with .Net framework v1.1.

WinFX SDK .NET Framework Version Incompatible with July CTP Version

Sam Gentile's Blog — Wed, 03 Aug 2005 19:39:19 GMT

WinFX SDK .NET Framework Version Incompatible with July CTP Version

Sam Gentile's Blog — Sat, 13 Aug 2005 16:44:47 GMT

re: Publisher policy, redirection cross major/minor version, and using the latest version

drabe — Wed, 24 Aug 2005 19:33:21 GMT

I have a .Net user control that I developed in VS.Net 2003, and I'm hosting it in MSIE as described in http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx. Works great on a system that has only .NET 1.1 installed. If I try to run it on a machine that also has .NET 2.0 beta installed, then I get all sorts of unexpected security exceptions. The IEHost log (as described in http://support.microsoft.com/default.aspx/kb/313892) reveals that IE is using some version 2 assemblies. Is there a way for me to force it to use v1.1 assemblies in this scenario?

<pre>Microsoft.IE.SecureFactory: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.UIPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32 checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Windows.Forms.Control.set_AllowDrop(Boolean value)
at OpenText.Livelink.SharePoint.Client.MultiUploadCtrl.InitializeComponent()
at OpenText.Livelink.SharePoint.Client.MultiUploadCtrl..ctor()
The action that failed was:
Demand
The Zone of the assembly that failed was:
Trusted
</pre>

Thanks,
--Dan

re: Publisher policy, redirection cross major/minor version, and using the latest version

Hugh Williams — Fri, 26 Aug 2005 17:28:55 GMT

I read <a href="http://wesnerm.blogs.com/net_undocumented/2005/04/the_art_of_thre.html">here</a> that Jeff Richter has backed off the new versioning scenario as described in the ServerSide article you mentioned.

Do you have any insight into what's going on there?

re: Publisher policy, redirection cross major/minor version, and using the latest version

junfeng — Sun, 28 Aug 2005 09:24:43 GMT

We are talking about future here so nothing is settled.

I use Jeff's article to introduce the concept of platform assemblies and library assemblies. That is my only purpose.

GAC assembly deployment nightmare | keyongtech

GAC assembly deployment nightmare | keyongtech — Thu, 22 Jan 2009 07:59:00 GMT

PingBack from http://www.keyongtech.com/482733-gac-assembly-deployment-nightmare