edit: don't worry about it charles, I've give it another go tomorrow (btw the size doesn't bother me at all).

posted by stevo_

(We don't need to have this conversation on this thread, however - Click on the Contact Us link on the bottom of the page and we can do this over email)

C

posted by Charles

I don’t have an issue with this change but please make sure you get the word out to developers.  I would also suggest adding an option to the manifest to allow the previous behavior (allow exe to run on any framework higher than the target).

posted by achopp

posted by joechung

C

EDIT: I have verified that there is no problem with the file itself and I've successfully downloaded it on two different networks. Seems the root cause is related to geographic location (CDN nodes are perhaps not evenly distributed) and network issues.

posted by Charles

We did spend a lot of time discussing how we will support developers that want a different trade-off - i.e. are willing to take the risk of allowing their app to run on a future version of the framework without having tested it.  This is one of the main reasons we now support 2-part version numbers in config files.  So, you can get almost what you suggest by adding <supportedRuntime version="v4.0"/> to your app's config (and if you really want ALL future versions, you could add v5.0, v6.0, v7.0, etc. - but I wouldn't reccomend it, there's a reasonable chance a complex app tested only against V2 will NOT run well on some CLR released 10 years from now <grin>).

Anyway, I definitely agree with your point about needing to do a good job "getting the word out".  I've forwarded your comments to the SxS team and we're discussing how best to document this and other potentially surprising behavior related to SxS.

Thanks!

     Rick

posted by RickByers

However, this sort of scenario (composable 3rd party components) is one of the main reasons why binary compatibility is still so important for the CLR.   Just like with .NET 1.x->2.0, we fully expect assemblies compiled against .NET 2.0 to be loaded into the 4.0 runtime.  So most of the time, rolling an application forward to 4.0 that has dependencies on 2.0 assemblies should hopefully just work fine.  One notable exception I discuss in the video is IJW assemblies (C++/CLI compiled without /clr:pure or /clr:safe) - those will unfortunately either need to be recompiled or the application will have to be configured to disallow the V2 runtime from being loaded.

I can imagine some rare cases though where this could be useful (depending on, for example, code though a COM interface that is implemented in .NET 2.0 and doesn't work on 4.0).  And the ASP.Net team does believe there is some value here.  But it'll probably be rare, and not a high priority scenario in 4.0.

Rick

posted by RickByers

Thanks for the reply.  What will happen when a new OS does not support the older framework (ie .net 1.0 will not install on Vista)?  You have forced the user to get an update for the application to support the new OS.  Is the Windows team ok with that?  It makes the OS look bad because it is no longer compatible with the application.  The easy answer is to always ship the older framework with the new OS, but I don't think that is going to happen.  This change is effectively putting a limit on the life of the app.  Again I am not against this change, I am simply trying to help find the holes.

posted by achopp

posted by stevo_

First a couple follow-ups from your original post after talking to some folks on the team.  How exactly are you detecting whether there is any CLR >= version 2 on the machine?  Since CLR v4 is intentionally hidden from the existing CLR v2 APIs, your code may actually do the desired thing and detect NO clr installed.  Also, we've improved the experience on this sort of failure by popping a dialog saying something like "this application requires CLR v2.0 in order to run - click here to download it".  Not perfect of course, but hopefully a helpful mitigation.

Now for your OS question.  Yes - big picture removing OS support for a version of the framework is a BIG compat decision.  Due to the problem of perfect compatability I discussed in the video, doing this at all is always going to be an issue - regardless of our roll-forward policy (even if we did roll forward, as we did 1.1->2.0, large apps have historically been likely to break unfortunately).  Windows has a similar philosophy in that they work hard to maintain compat, but know they can't be perfect and so also rely on mitigations like compat labs and app-compat shims.  We do the same thing - running the most popular .NET apps in our labs, and where it's advantageous including app-specific compat policy with a new .NET Framework release (take a look at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\AppPatch\v2.0.50727.00000 for example - it lists applications that are known to be incompatible with v2 and so should not roll-forward, we can do a similar thing in v4 where we can list apps that we've tested and know work with v4 and so should be rolled forward).  This of course is only helpful for the biggest most popular apps, but it's helpful nontheless.  Also, OS upgrade boundaries change the compat formula a bit and may influence the policy we choose to apply.  For example, it's possible that a future version of Windows will include only CLR V4 but will be configured to roll v2 apps forward to V4 (we have not made any decisions about what we WILL do here, just intentionally kept this open as an option - these decisions are all controled declaratively by the upgrade policy in the registry).  The key thing we need to avoid is installing a new .NET Framework breaking some application that was previously working fine - upgrading the OS on that machine is a bit of a different equation.

Still far from perfect, I know.  But the compat space is all about trade-offs between lots of different less-than-perfect options.

Rick

posted by RickByers

A coworker best describes the dillema we faced in making this decision:

               "It’s a tradeoff of where we want the [error] to come from. Failing in a predictable way that leads to the solution vs. failing in a unpredictable (possibly destructive) way with no indication of how to fix it.  I think we’ve made the right choice here."

Let me expand on this.

It is almost always the case, even when a high compatibility goal is in place, that software will diverge with each subsequent major version release as a result of innovation and bug fixes (security bug fixes are the most obvious here). These changes will invariably lead to (sometimes very subtle) breaking changes, both intentional (for example, security bug fixes) and unintentional. As a result, applications that worked correctly on one version of the runtime could malfunction (also in a very subtle way) when run on a later version.

This is precisely the motivation in eliminating the default roll-forward policy in the v4.0 release of the .NET framework. While we strive to make each version of the .NET Framework highly compatible with previous releases with the goal that the vast majority of applications will "just work", we still want authors to evaluate their applications on each release and explicitly opt into running on them.

Thanks,
Simon

posted by SimonHall

Thanks for all the feedback.  Keep up the good work.

posted by achopp

C

posted by Charles

really interessting stuff you got their!  Their is only one point i still struggle with: "Assumed i have the level of isolation you mentioned in the video, is it possible to load to an managed clr2 application the clr4 runtime In-process SxS (and vice versa)?  If yes, what do i have to do? Is their any managed api i have to call? Or do i need the come layer or something which then loads the other clr for me?  Are their any samples for the beta1 where i can have a look at?

Thanks

DG

posted by DanDG

CLR loading is really something that happens through native APIs, either using hosting APIs directly (eg. ICLRMetaHost), or indirectly via COM.  You can do this in managed code (no need to actually write any native code) by using .NET's interop facilities.  So yes, you could write code that ran in CLR v2 which loaded CLR v4 and vice-versa. 

I know we've got some code samples in the works, but I don't think they've been posted yet.  Keep an eye on the SxS category of the CLR team blog. The simplest way is to build a managed COM component using one version of .NET, and then instantiate it using COM-interop from another version of .NET exactly as you would without SxS.  Look for any samples for building and using COM components with .NET 2.0.

I hope this helps,

   Rick

posted by RickByers

thanks for the fast response! That really helps.

Just to make sure that i got it right: In order to use SxS you have to call the hosting API. This can be done directly (in native code or in managed code by using interop facilities) or indirectly via COM. In the COM scenario the hosting API is called automatically for me within the COM functionality?

Therefore the easiest way to get an running example of calling CLR SxS in an managed application is using COM in a cross clr scenario. The other way is to do this manually by calling the hosting API...

Thanks

Daniel

posted by DanDG