Re: Common Library .NET and CF.NET

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Elmer Miller (millere_at_empireco.nospam)
Date: 08/24/04 

Date: Tue, 24 Aug 2004 15:35:14 -0400

Another object that doesn't correctly implemnt IDisposable as documented is
SqlCeDataAdapter. It should implemnt IDisposable because of inheriting from
Component, but it doesn't. It does, however, implement Dispose()

"Elmer Miller" <millere@empireco.nospam> wrote in message
news:OPVg9f8fEHA.3700@TK2MSFTNGP12.phx.gbl...
> Another example of wierdness related to IDisposable is the fact that the
> SolidBrush implements Dispose but does not seem to implement IDisposable.
> If
> you try to use a SolidBrush in a 'using' statement like:
> using (SolidBrush b = new SolidBrush(Color.Black))
>
> You get a compiler error stating that: Cannot implicitly convert type
> 'System.Drawing.SolidBrush' to 'System.IDisposable'
> It must be that SolidBrush does not implement IDisposable, but since
> SolidBrush inherits from Brush which is documented to implement
> IDisposable,
> I don't understand why this error occurs.
>
> "Andreas Selle" <me@privacy.net> wrote in message
> news:%23iOdZqfeEHA.2044@TK2MSFTNGP10.phx.gbl...
>
>> Hi,
>>
>> I made exactly that - several times. Here are my experiences and
>> suggestions.
>>
>> 1) Of course you have to limit your usage of the .NET Framework to the
>> common subset of both.
>>
>> 2) In my components I avoid to have _any_ GUI stuff in the components
>> that
> I
>> share among .NET and .NETCF. I guess you should avoid having any GUI
>> stuff
>> in your libraries, too. The GUI is what makes the platforms so different.
> So
>> leave that to the platform specific application and outside of commonly
> used
>> libraries.
>>
>> 3) You must test thoroughly on both frameworks because there are some
> subtle
>> differences (Some that I found and remember:
>> String.Replace(string,string)
>> with newValue=null works on big .NET as documented but leads to exception
> on
>> .NETCF; HttpWebResponse is IDisposable and must be disposed in big .NET
> but
>> does not even implement IDisposable in .NETCF; etc...). Expect to find
> quite
>> a few of such small compatibility glitches.
>>
>> 4) If you encounter a serious incompatibility, or even have to do some
>> P/Invoke stuff (which is almost always different), it is probably best to
>> use some conditional compilation (in C#: #if / #else / #endif). I don't
> know
>> whether there is any officially suggested symbol for .NETCF, I just
>> define
>> and use WINCE and bracket platform dependend code with #if WINCE / #else
>> /#endif. IMHO: Visual Studio should define some platform symbol in all
> Smart
>> Device Projects by default.
>>
>> 5) The resulting binary .dll of a build is not fully portable across .NET
>> and .NETCF. It is in some cases (.NETCF builds should work on full .NET
> 1.1)
>> but not in the general case.
>>
>> 6) Therefore, you must make two completely separate builds. One as a
>> Smart
>> Device Application project (although it will only be a library), and
> another
>> as a Class Library project (always assuming you will use Visual Studio).
>> Both builds can be made from the same source code though.
>>
>> 7) To organise these builds, perhaps the best solution is to use
>> VisualSourceSafe. There you can create two separate project branches and
>> share all common source code between these branches. Thus you can be sure
>> that both builds are always made from the same source code. Do not share
> the
>> project files .csdproj and .csproj as these are different. Also I do not
>> share the AssemblyInfo.cs as I use that to mark my builds differently. To
> do
>> so, you will have to use VisualSourceSafe through its own GUI and disable
>> the VSS integration in Visual Studio which always messes things up if you
>> have shares. (Interestingly the old pre-.NET Visual Studio was able to
>> handle this. The new VisualStudio.NET VSS integration got much worse and
> is
>> better switched off completely)
>>
>> Final advice: The complete .NET reference documentation is obviously made
>> from the full .NET framework (and development team) and there is no
>> _real_
>> documentation of the .NETCF. Therefore it often contains information that
> is
>> plain wrong for the .NETCF. So take care and test a lot.
>>
>> Good luck!
>>
>> --
>> Andreas Selle
>> http://subsembly.com/
>>
>>
>
>

Relevant Pages

  • Re: Common Library .NET and CF.NET
    ... SolidBrush implements Dispose but does not seem to implement IDisposable. ... > in your libraries, too. ... > as a Class Library project (always assuming you will use Visual Studio). ... The complete .NET reference documentation is obviously made ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Standard Library Interest? (The Big Player ACT)
    ... No hypertext can help here. ... that documentation sitting on someone else's shelf didn't help me one ... There's nothing wrong with a "Fundamentals of the Conventional Ada ... > (It appears that container libraries such as Charles or Booch's ...
    (comp.lang.ada)
  • Re: Standard Library Interest? (The Big Player ACT)
    ... > documentation even come with the distribution? ... > hyperlink to the code after installation - or, more importantly, does ... the ARG in terms of documentation of whatever they included in an Ada ... you came across two libraries that do the same thing, ...
    (comp.lang.ada)
  • Re: JavaDocs vs. Tests (was: Interview)
    ... documentation for what the method actually does. ... Say we've got a function formatName which takes a Person object and gives you a string like "J. ... For libraries, it certainly makes sense, but for applications.. ... What's a bit weird is that in its released form, it *doesn't* have tests - the tests for it are actually tests for a demo app written on top of the library. ...
    (comp.lang.java.programmer)
  • Re: cpu overheating
    ... That's why you have graphics libraries on a headless server. ... Some of these things are required to conform to some standard or other expectation of functionality, but by and large, they're components without which things just won't *work*. ... A bare installation is still somewhere in the neighborhood of six or seven hundred megs (of which, around two hundred is manual pages, documentation, and string translations, vastly out sizing the "optional" dependencies), which is hardly unreasonable. ... Perhaps I mightn't even want to install the documentation. ...
    (Fedora)