Enterprise Library 3 on Windows 2000

Topics: Caching Application Block , Data Access Application Block, Enterprise Library Core
Apr 17, 2007 at 4:27 PM
Just realized the system requirement for Enterprise library 3 is windows XP above. The version 2 on January 2006 still supports windows 2000 according to the documents.

If we stay with .NET 2 framework without referencing any .NET 3.0 features, is it safe to use the enterprise library 3 on windows 2000 environment. Half of the company machines are still running windows 2000 and there is no plan for the migration in the near future.

Any comments are welcomed.
Apr 17, 2007 at 5:22 PM
We didn't test EntLib 3.0 on Windows 2000 so we can't make any guarantees about how well it will work, but I can't think of any reason why it wouldn't work.

Apr 17, 2007 at 8:47 PM
Would the host OS only play a part if the .NET application is not CLR compliant or something to that nature. Do we not write application for .NET regarldes of the host OS? I know there is only one model of .net Microsoft, but we can't forget there is MONO or even the idea of .NET everywhere on any cpu or on any host. I'm bit puzzled because the concept was that if you write CLR compliant .net then it would run on that version of .net regardless of the host OS. I know that there is the Bass Class Library, but is there or are there some libraries for only a particular OS 2003/vista/xp but not on windows 2000 let alone NT 4.0 or 3.51? Or could there be win32 interop calls that are OS dependant?

Could one run EntLib on MONO? -no- Generlly speaking how would one know when writing for .net that they have stepped out of the CLR world and that the program may now become OS dependant?

I'm going along the lines of "if .NET works on the host OS then I could compile and run CLR compliant code?" for which .net does not run on 4.0 or 3.51 so I would deffenitly assume EntLib would not work on those. But .NET 2.0 works on windows 2000 so am I now to have some doubts that .net apps will not work on windows 2000 based on this post? Unless there are some technical factors to determine when a .net application becomes OS dependant? Mono is almost CLR compliant and one could take clr compliant code from ms .net app and compile with MONO. Granted simple appliations like Hello World. But mono is the extrema left I'm just wondering with in the MS umbrella when .net will break on different OS and interop win32 is the only area I could think of other than some class library like WPF that is specific to the OS.

Could one or is there a way to audit assemblies to determine what is being used and if a particular OS would support it or not?

Apr 17, 2007 at 9:48 PM
In general .NET is .NET, although there are some subtle differences in how certain things like WCF and ASP.NET work on different OSes. Hoewever more importantly there can be OS-specific differences that impact things like installers, documentation, scripts etc. So even if the core code will work anywhere, we do make sure we test across common supported OSes to ensure all of the small details work as expected.

Apr 18, 2007 at 12:11 AM
Ahh, it may work in part or in whole on MONO but an MSI installer will not work, catch-22. As well as the installer not working on older window versions. But that brings up a question, is the source code packaged in a more friendly format like .zip? One could say a particular AB will work but depending on if the core assemblies work or not (common, objectbuilder, etc..) if not then nothing would.