On 2011-08-15, Roy Chastain wrote: > Let me start at some basics just to ensure that we are starting at the > same point. > There are 3 CLR versions, 1.x, 2.0, 4.0. Framework 3.0 and 3.5 are > simply add on assemblies that target the 2.0 runtime. This fact is why > the 3.5, 3.0 and 2.0 interop works so well. That is also why the > service pack for 3.5 updates the 3.0 and 2.0 assemblies.
> 4.0 targeted runtime can call into 2.0 CLR code. The problem is that > both the 4.0 and 2.0 CLR must be present on the system. I knew so much, but thank you anyway - I'd likely have needed way more words. > This leads to a distribution package that may need to install both the > 3.5 SP1 (the best way to get a 2.0 Framework installed) and the 4.0 > frameworks. This is what I didn't know. My development machine doesn't list any framework other than 4.0 as installed but still I can use the log4net assembly that targets 2.0. Probably the installation of VS installed the older frameworks. Anyway, for some reason I was under the impression the 4.0 framework install would contain the 2.0 CLR. > The dual framework package is not much of issue for Windows 7 systems, > because Win 7 and Server 2008 r2 come with a completely patched 3.5 > framework. OK, my case - and the production envs are either old Win 2003 servers that used to have 2.0 installed before adding 4.0 or Win 2008 server, this explains why we have never seen any issues. > We need/must have a 4.0 targeted assembly (someday soon - not today) so > that applications that are built against 4.0 will only require 4.0 and > not 3.5 and the rest of the 2.0 CLR. This should actually be doable for 1.2.11 with the latest NAnt alpha, I'll see to it. > We must also have assemblies that target both the full and client > frameworks of 4.0 and (I believe lessor priority) 3.5 (again a polling > question). Yes, I agree by now. > The second set of traffic is that "log4Net does not log anything when I > call it for code compiled for .NET Framework 4.0". When asked, the > response has usually been that they were attempting to use an ADO > appender. I know the rolling file, SMTP and console appenders all work > correctly, but I have never tried an ADO appender on any version. Same here. > I have just uncovered and am in the process of having Microsoft look > at an issue in the 4.0 to 3.5 interop. In my application that uses > both, the 4.0 code runs just fine, but when it is attempts to call the > 3.5 code it gets an untrapped but ignored exception. This happens on > a clean install of 3.5 SP1 and 4.0 on a clean XP system. The > interesting thing is that a system restart resolves the issue and the > application then runs. Ouch. >>> And then we add conditional compilation on a CLIENT_PROFILE that >>> removes all System.Web references and target 2.0 again but this time >>> with the symbol set. Shouldn't the resulting assembly work for the >>> 3.5 and 4.0 client profiles? > Assuming that the reference to the missing assembly is dropped as you > suggested, I will agree to the 3.5 client profile. (I am not saying > that it is not dropped, I just do not have knowledge of that one way > or the other.) An application targeting the 4.0 client profile will > still require the install of the 3.5 client profile if we do not > target 4.0 during the build of the assemblies. Let me try some things with NAnt, I'm pretty confident we'll be able to create assemblies targeting both client profiles in time for the 1.2.11 release as well. Stefan
