Im writing .NET libraries for .NET Framework and .NET Compact Framework too.
What is the best practices to write 'multi-platform (.NET Framwork / .NET
Compact Framework)' libraries

:)

(Which attribute says; in my class; that this member of a class is .NET
Compact Framework compatible)

Thanks fot tips

Mirek

Re: Best practices in .NET libraries compatible to Compact Framework by Frans

Frans
Mon Jul 03 03:57:02 CDT 2006

Mirek Endys wrote:

> Im writing .NET libraries for .NET Framework and .NET Compact
> Framework too. What is the best practices to write 'multi-platform
> (.NET Framwork / .NET Compact Framework)' libraries
>
> :)
>
> (Which attribute says; in my class; that this member of a class is
> .NET Compact Framework compatible)

I'm not familiar with such an attribute. The thing is that for .NET it
doesn't matter if you're compiling for the compact framework or normal
.NET, as you're using the same compiler, you just link with another
mscorlib and framework assemblies ;)

In general, everything remoting related should be avoided. Also,
things like:
myStringBuilder.AppendFormat("..."... )
should become:
myStringBuilder.AppendFormat(null, "...

but that's mostly it. To get my o/r mapper core running on the CF.NET
framework I wrote a couple of dummy classes which do nothing on the
CF.NET and I simply add that set of classes to the code when I'm
compiling against the CF.NET. This then helps me avoid to add a lot of
conditional compilation statements in the code and I can keep
[Serializable()] etc. in my code. :)

So I'd invest some time in that set of classes, which isn't that hard,
and then just develop for the normal .net framework. Porting the code
over would then be a piece of cake :)

Frans

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Re: Best practices in .NET libraries compatible to Compact Framewo by MirekEndys

MirekEndys
Mon Jul 03 04:21:02 CDT 2006

Hello Frans,

I thought, that I can compile my own library, that can be used in both
project ('normal' .NET Framework and Compact .NET Framework). This compiled
library contains objects that I want to use in both projects (like an Order,
or Customer is). But there are helper functions, that can be used only on the
'normal' Framework - like... SendBroadcast or something similar that is
useable only in PC environment.

For example:

Im writing base clases for our business solution like Order, Customer etc.
These object have same structure, same methods, same properties for
Windows-Form apps, .NET.ASP apps, and mobile, PocketPC apps. I would like to
write library, that is useable for both platforms (one library) .. and I
thought, that I can write one library project, and then I have to sign the
methods by an attribute like [CFSupported] or something similar only. Only
the methods, that are supported by CF (because not all methods can be used on
CF)


It seems Im wrong and I have to write two version of my own business
framework. Thats weird.

Thanks for any idea

Mirek.

"Frans Bouma [C# MVP]" wrote:

> Mirek Endys wrote:
>
> > Im writing .NET libraries for .NET Framework and .NET Compact
> > Framework too. What is the best practices to write 'multi-platform
> > (.NET Framwork / .NET Compact Framework)' libraries
> >
> > :)
> >
> > (Which attribute says; in my class; that this member of a class is
> > .NET Compact Framework compatible)
>
> I'm not familiar with such an attribute. The thing is that for .NET it
> doesn't matter if you're compiling for the compact framework or normal
> ..NET, as you're using the same compiler, you just link with another
> mscorlib and framework assemblies ;)
>
> In general, everything remoting related should be avoided. Also,
> things like:
> myStringBuilder.AppendFormat("..."... )
> should become:
> myStringBuilder.AppendFormat(null, "...
>
> but that's mostly it. To get my o/r mapper core running on the CF.NET
> framework I wrote a couple of dummy classes which do nothing on the
> CF.NET and I simply add that set of classes to the code when I'm
> compiling against the CF.NET. This then helps me avoid to add a lot of
> conditional compilation statements in the code and I can keep
> [Serializable()] etc. in my code. :)
>
> So I'd invest some time in that set of classes, which isn't that hard,
> and then just develop for the normal .net framework. Porting the code
> over would then be a piece of cake :)
>
> Frans
>
> --
> ------------------------------------------------------------------------
> Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
> LLBLGen Pro website: http://www.llblgen.com
> My .NET blog: http://weblogs.asp.net/fbouma
> Microsoft MVP (C#)
> ------------------------------------------------------------------------
>

Re: Best practices in .NET libraries compatible to Compact Framewo by Simon

Simon
Mon Jul 03 14:23:20 CDT 2006

This is not strictly true.

You can write one library that will run on both the Windows CE device and
the desktop by setting the library application as a smart device project.
This is because smart device projects use retargetable assembly references
which can be used on both the CF and the desktop but the opposite is untrue.
You can't compile for desktop and run on CF.

There is no such attribute as [CFSupported]. You have the limitation of the
CF libraries when you compile for both CF and Desktop.

Regards
Simon.


"Mirek Endys" <MirekEndys@discussions.microsoft.com> wrote in message
news:68FCAD43-88E9-4C6D-B37E-E6056E686459@microsoft.com...
> Hello Frans,
>
> I thought, that I can compile my own library, that can be used in both
> project ('normal' .NET Framework and Compact .NET Framework). This
> compiled
> library contains objects that I want to use in both projects (like an
> Order,
> or Customer is). But there are helper functions, that can be used only on
> the
> 'normal' Framework - like... SendBroadcast or something similar that is
> useable only in PC environment.
>
> For example:
>
> Im writing base clases for our business solution like Order, Customer etc.
> These object have same structure, same methods, same properties for
> Windows-Form apps, .NET.ASP apps, and mobile, PocketPC apps. I would like
> to
> write library, that is useable for both platforms (one library) .. and I
> thought, that I can write one library project, and then I have to sign the
> methods by an attribute like [CFSupported] or something similar only. Only
> the methods, that are supported by CF (because not all methods can be used
> on
> CF)
>
>
> It seems Im wrong and I have to write two version of my own business
> framework. Thats weird.
>
> Thanks for any idea
>
> Mirek.
>
> "Frans Bouma [C# MVP]" wrote:
>
>> Mirek Endys wrote:
>>
>> > Im writing .NET libraries for .NET Framework and .NET Compact
>> > Framework too. What is the best practices to write 'multi-platform
>> > (.NET Framwork / .NET Compact Framework)' libraries
>> >
>> > :)
>> >
>> > (Which attribute says; in my class; that this member of a class is
>> > .NET Compact Framework compatible)
>>
>> I'm not familiar with such an attribute. The thing is that for .NET it
>> doesn't matter if you're compiling for the compact framework or normal
>> ..NET, as you're using the same compiler, you just link with another
>> mscorlib and framework assemblies ;)
>>
>> In general, everything remoting related should be avoided. Also,
>> things like:
>> myStringBuilder.AppendFormat("..."... )
>> should become:
>> myStringBuilder.AppendFormat(null, "...
>>
>> but that's mostly it. To get my o/r mapper core running on the CF.NET
>> framework I wrote a couple of dummy classes which do nothing on the
>> CF.NET and I simply add that set of classes to the code when I'm
>> compiling against the CF.NET. This then helps me avoid to add a lot of
>> conditional compilation statements in the code and I can keep
>> [Serializable()] etc. in my code. :)
>>
>> So I'd invest some time in that set of classes, which isn't that hard,
>> and then just develop for the normal .net framework. Porting the code
>> over would then be a piece of cake :)
>>
>> Frans
>>
>> --
>> ------------------------------------------------------------------------
>> Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
>> LLBLGen Pro website: http://www.llblgen.com
>> My .NET blog: http://weblogs.asp.net/fbouma
>> Microsoft MVP (C#)
>> ------------------------------------------------------------------------
>>



Re: Best practices in .NET libraries compatible to Compact Framewo by Frans

Frans
Tue Jul 04 03:22:01 CDT 2006

Mirek Endys wrote:

> I thought, that I can compile my own library, that can be used in
> both project ('normal' .NET Framework and Compact .NET Framework).
> This compiled library contains objects that I want to use in both
> projects (like an Order, or Customer is). But there are helper
> functions, that can be used only on the 'normal' Framework - like...
> SendBroadcast or something similar that is useable only in PC
> environment.

Oh I have that too. If the methods are inside classes also used on the
CF.NET framework, I mark them with:
#if !CF
//...
#endif

And with the CF builds I pass 'CF' to the compiler, so that code gets
excluded. If the class itself isn't used on CF, I don't include it in
the build. I use own buildscripts with nmake but this also works with
msbuild of course.

> For example:
>
> Im writing base clases for our business solution like Order, Customer
> etc. These object have same structure, same methods, same properties
> for Windows-Form apps, .NET.ASP apps, and mobile, PocketPC apps. I
> would like to write library, that is useable for both platforms (one
> library) .. and I thought, that I can write one library project, and
> then I have to sign the methods by an attribute like [CFSupported] or
> something similar only. Only the methods, that are supported by CF
> (because not all methods can be used on CF)
>
>
> It seems Im wrong and I have to write two version of my own business
> framework. Thats weird.

No you don't have to :) Please re-read my previous post, I probably
didn't explain it well enough, but you should just write your code for
normal .net and create some dummy classes for the cf.net code so it's
compilable, and exclude some routines here and there.

Frans

>
> Thanks for any idea
>
> Mirek.
>
> "Frans Bouma [C# MVP]" wrote:
>
> > Mirek Endys wrote:
> >
> > > Im writing .NET libraries for .NET Framework and .NET Compact
> > > Framework too. What is the best practices to write
> > > 'multi-platform (.NET Framwork / .NET Compact Framework)'
> > > libraries
> > >
> > > :)
> > >
> > > (Which attribute says; in my class; that this member of a class is
> > > .NET Compact Framework compatible)
> >
> > I'm not familiar with such an attribute. The thing is that for
> > .NET it doesn't matter if you're compiling for the compact
> > framework or normal ..NET, as you're using the same compiler, you
> > just link with another mscorlib and framework assemblies ;)
> >
> > In general, everything remoting related should be avoided. Also,
> > things like:
> > myStringBuilder.AppendFormat("..."... )
> > should become:
> > myStringBuilder.AppendFormat(null, "...
> >
> > but that's mostly it. To get my o/r mapper core running on the
> > CF.NET framework I wrote a couple of dummy classes which do nothing
> > on the CF.NET and I simply add that set of classes to the code when
> > I'm compiling against the CF.NET. This then helps me avoid to add a
> > lot of conditional compilation statements in the code and I can keep
> > [Serializable()] etc. in my code. :)
> >
> > So I'd invest some time in that set of classes, which isn't that
> > hard, and then just develop for the normal .net framework. Porting
> > the code over would then be a piece of cake :)


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------