When is it okay to reference WindowsBase.dll?

tags:

.net

views:

243

answers:

+1 Q:

When is it okay to reference WindowsBase.dll?

I've heard/read about people not wanting to reference the assembly because of the Windows component (e.g. "I don't want to reference Windows for my Web App).

I'd like to hear what a large community feels about this.

For which project types (business, data access, etc.) is it considered acceptable to reference WindowsBase.dll.

WindowsBase is a DLL that is a part of the WPF framework. It should only be referenced in WPF EXE's or DLL's that are used inside of a WPF application. Doing otherwise is taking a dependency on WPF in a non-WPF application.

Using this in a DLL such as a Web App will likely work for some cases but will almost certainly cause you pain in the future as you're combining two incompatible technologies.

JaredPar 2010-03-19 21:50:22

This is a more interesting question when heard as "I want to call a useful method in System.Forms, WindowsBase, etc. I won't be using the windowing tools provided by those libraries. Why is it considered bad practice to reference those libraries from my web app?"

Michael Petrotta 2010-03-19 22:00:00

I disagress with such a rather strict statement. WindowsBase.dll was introduced with .NET 3.0 together with WPF but it contains also non-WPF namespaces such as `System.IO.Packaging`. E.g. Microsofts OpenXML has a dependency on that namespace (IIRC), and if your statement was true, no server-side document automation scenario using the OpenXML SDK was a good idea...

0xA3 2010-03-19 22:06:25

Are they really incompatible? Why can't I use WPF's features to create a static chart that is then served to the client as JPEG?

Jonathan Allen 2010-03-19 22:08:40

@divo, i'm speaking from the standpoint of experience here. In order for this to work you must know the strict subset of types and methods that's OK to use, have the discipline necessary to only use it, be able to pass down both of these to future developers and bet that WPF won't evolve in such a way to invalidate your assumptions.

JaredPar 2010-03-19 22:12:59

Yes, true, and I think this holds for almost any reference you add to a project.

0xA3 2010-03-19 22:48:09

@divo, no I don't believe so. This is only a requirement because you're using a DLL in a manner that is not intended. Using a WindowsBase.dll in a WPF application has not of these restrictions because it's intuitively supported for that scenario.

JaredPar 2010-03-19 22:55:48

-1, quite disagree. System.Collections.ObjectModel.ObservableCollection, System.IO.Packaging.ZipPackage, System.Windows.Vector, useful classes in many programs. This kind of thinking prevents C# programmers from using the great goodies in Microsoft.VisualBasic.dll. No, it doesn't turn your C# code in the, yuck!, Visual Basic.

Hans Passant 2010-03-20 01:17:13

@nobugz, it's interesting that you would mention `ObservableCollection`. This type was so useful that in 4.0 it was moved out of WindowsBase and into System. It had use cases outside of WPF and putting it into WindowsBase restricted it's valid uses, moving it into system fixed that.

JaredPar 2010-03-20 06:20:03

If it's "bad" to use WindowsBase outside WPF then I don't understand the way namespaces are put together in an assembly. I see no fundamental link between `System.IO` (`.Packaging`) or `ObservableCollection` and WPF at all (besides that WPF heavily makes use of the latter). Is there some article or post explaining how the BCL team decides which namespace goes into which assembly? E.g. why those two namespaces didn't go into System.dll or a separate assembly? It seems quite a limitation to me if types with rather broad use cases such as collections and packaging are grouped together with ...

0xA3 2010-03-20 11:21:10

... a specific framework and hence the usage of this type is bound to the specific framework.

0xA3 2010-03-20 11:21:30

And regarding the point about "pain in the future": It goes without saying that a migration to newer versions of referenced assemblies should always be accompanied by excessive regression testing. Even if the authors of those references take special care not to break existing code, experience has shown that breaking changes can still occur (I remember some date formatting issues when migrating from .NET 1.1 to .NET 2.0).

0xA3 2010-03-20 11:27:18

@Jared, nothing got "fixed", it merely was an optimization. Using ObservableCollection only costs some VM space for the .ni.dll. Even that optimization is questionable, it now costs more VM space for any process that *doesn't* use ObservableCollection. Can you elaborate the fix?

Hans Passant 2010-03-20 13:47:24

@nobugz I would consider the fix to be moving a generally useful type into a more general assembly instead of leaving it in a more application specific one.

JaredPar 2010-03-20 17:50:47

What is the harm of taking on a dependency to a DLL shipped with the .NET framework?

Slight longer startup times

How often should a web site restart?

Maybe once a month

If it were the other way around, using System.Web from a WPF program, you might have a concern because you wouldn't be able to use the Client Framework, you would have to use the full version. But in this case those people are just being stupid.

Jonathan Allen 2010-03-19 22:06:08

ansaurus

tags:

views:

answers:

When is it okay to reference WindowsBase.dll?

related questions