First thing which will be added soon is Compact Framework support (CF), for ORMSUpport classes, generated code and SqlCE.

I'm currently porting the ORMSupportClasses code, that is: writing dummy classes for code which isn't used (like remoting code) so the code gets compiled and I'm also adding conditional compiles.

I've a hard time with the Xml code of the CF, or better: lack thereof. As there is no XPath support, I have to write my own SelectSingleNode routine (i've written a small loop in a utility class which I hope will work) and also SelectNodes is missing.

Is there a utility library available which has this kind of utility code? I already found OpenNETCF.org, and it will be useful for the generated code to work, but it lacks XPath classes as well...

Another issue is that the reflection code on the CF framework almost doesn't exist, so I can't check which attributes are defined on properties, at least I don't know how. This results in the fact that XmlIgnore attributes are ignored, (and the property thus ends up in the XML or it makes the code crash, have to figure that out) and for example the derived entities collections in adapter won't work in a databinding scenario (but I don't know if databinding works on the CF).

All in all, I'm not sure if this in the end will be an experience we all want. I hope it will pay off, but if not, I think I have to write some sort of crappy dataset wrapper lib, and I don't know what's worse.

So if anyone has any resources for the CF with utility libs, it would be great

Ok, the ORMSupport classes compile! (and THUS it works! )

Tomorrow, I'll see if I can get the generated code to compile. What I want to achieve is that I don't have to create new templates, just use the existing ones. But that might not be possible...

As soon as I have a compilable piece of code, I'll post a set of files for you all to try out.

Looking forward to it

My ipaq is ready and willing.

Hmmm...I'm afraid to ask: but, are the entities and interfaces actually new types? It sounds like it, especially as one has to recompile specifically against the CF Framework. How will this affect interoperability? Can I write a business layer that can work with both Windows Mobile as well as traditional and web clients?

Jeff...

jeffreygg wrote:

Hmmm...I'm afraid to ask: but, are the entities and interfaces actually new types? It sounds like it, especially as one has to recompile specifically against the CF Framework. How will this affect interoperability? Can I write a business layer that can work with both Windows Mobile as well as traditional and web clients? Jeff...

Not the same compiled assembly. The idea is (as I see it) that you can have entities on a CF device, use the local db and/or a webservice.

You can of course recompile the BL on CF, and that should work. (as I see it now, you probably have to reference another ormsupportclasses dll but that's about it)

It can be I will hit some roadblocks, for example memory usage, because I've very little experience with the CF. I'll first port everything (except remoting, delegates in UoW and COM+ support) to the CF and will take it from there. One of the core things which should be possible is that you have a webservice, setup with your sqlserver generated code, (or oracle, whatever database) and you produce Xml which is consumed on the client, with its own generated code (for example a subset of the entities), modifies them and sends them back, eventually storing the entities locally in SqlCE for the time being.

Otis wrote:

jeffreygg wrote:

Hmmm...I'm afraid to ask: but, are the entities and interfaces actually new types? It sounds like it, especially as one has to recompile specifically against the CF Framework. How will this affect interoperability? Can I write a business layer that can work with both Windows Mobile as well as traditional and web clients? Jeff...

Not the same compiled assembly. The idea is (as I see it) that you can have entities on a CF device, use the local db and/or a webservice.

You can of course recompile the BL on CF, and that should work. (as I see it now, you probably have to reference another ormsupportclasses dll but that's about it)

One would have to be very careful to use only the subset of functionality common to the CF and regular library

It can be I will hit some roadblocks, for example memory usage, because I've very little experience with the CF. I'll first port everything (except remoting, delegates in UoW and COM+ support) to the CF and will take it from there. One of the core things which should be possible is that you have a webservice, setup with your sqlserver generated code, (or oracle, whatever database) and you produce Xml which is consumed on the client, with its own generated code (for example a subset of the entities), modifies them and sends them back, eventually storing the entities locally in SqlCE for the time being.

A buncha things come to mind here. Is there a remoting framework available for CF? Perhaps a commercially available one? If so, it'd be nice if there was a technique that allowed you to build one remoted business layer that was callable from either platform. This would imply that somehow there were common types between the two frameworks, but I'm not thinking this is possible.

I wonder if it would be possible to build a special CF remoting/web services facade that translated between CF entities/collections and "normal" ones. Is the CF framework even installable outside of CE device?

Just some musings. If I'm still with my current client long term I'm sure they'll want me to develop some type of CF client. I've set up my business layer such that (hopefully) moving to a remoting or web services architecture won't be a problem. In this instance being able to reuse that layer for CF callers will be extremely valuable.

Jeff...

A buncha things come to mind here. Is there a remoting framework available for CF? Perhaps a commercially available one? If so, it'd be nice if there was a technique that allowed you to build one remoted business layer that was callable from either platform. This would imply that somehow there were common types between the two frameworks, but I'm not thinking this is possible.

The ERDA framework kinda supports this. It allows you to make your business logic transport independent. Then can create pretty much any transport you want to hook up to it. For instance, remoting for .NET clients, webservices for java/CF.Net etc etc... There was another post it about this framework earlier but i got the impression that people though it was the Enterprise Library which it is NOT!

Anyway, i just found it the other day, and i am still researching it so i dont know a whole lot about it yet.

http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=9c29a963-594e-4e7a-9c45-576198df8058

If the CF framework support becomes a problem, you could always make "adapters" to simpler objects. This would kill two birds with one stone, the problem of the stupid ms webservice tools and the CF.NET

Thanks; I'll check it out.

Jeff...

jeffreygg wrote:

Otis wrote:

jeffreygg wrote:

Hmmm...I'm afraid to ask: but, are the entities and interfaces actually new types? It sounds like it, especially as one has to recompile specifically against the CF Framework. How will this affect interoperability? Can I write a business layer that can work with both Windows Mobile as well as traditional and web clients? Jeff...

Not the same compiled assembly. The idea is (as I see it) that you can have entities on a CF device, use the local db and/or a webservice.

You can of course recompile the BL on CF, and that should work. (as I see it now, you probably have to reference another ormsupportclasses dll but that's about it)

One would have to be very careful to use only the subset of functionality common to the CF and regular library

Yeah, it's not that common. IMHO they've cut away way too much in CF.NET 1.x.

It can be I will hit some roadblocks, for example memory usage, because I've very little experience with the CF. I'll first port everything (except remoting, delegates in UoW and COM+ support) to the CF and will take it from there. One of the core things which should be possible is that you have a webservice, setup with your sqlserver generated code, (or oracle, whatever database) and you produce Xml which is consumed on the client, with its own generated code (for example a subset of the entities), modifies them and sends them back, eventually storing the entities locally in SqlCE for the time being.

A buncha things come to mind here. Is there a remoting framework available for CF?

No, just webservices. And very low level, no XPath for example.

Perhaps a commercially available one? If so, it'd be nice if there was a technique that allowed you to build one remoted business layer that was callable from either platform. This would imply that somehow there were common types between the two frameworks, but I'm not thinking this is possible.

That's indeed a great thing to have, I just wonder if it's indeed possible. Relying on a 3rd party remoting framework narrows the usefullness of the CF code I think.

I wonder if it would be possible to build a special CF remoting/web services facade that translated between CF entities/collections and "normal" ones. Is the CF framework even installable outside of CE device?

Only on an emulator . You can recompile code for the CF on .NET though (with some small exceptions)

You should be able to read the XML for an entity from a webservice, and re-instantiate an entity on the CF, work with it, and send it back. As what's transported is XML, it should be possible to receive the XML at the server again and re-instantiate an entity from it and save it to the db for example.

Most of the apps that I have build for the CF use the device for local storage then send the data to a central repository at a later time, either via web services or tcp/ip sql ce replication techniques.

So, having an ORM Support Library for the CF is very valuable and should save much time when coding the plumbing for sql ce DALs.

Most of my clients want to be able to scan data, save it local, then send it somewhere later. Some also want to scan it and send it after it is scanned, validate the scan on the server, and get a response back from the service.

So indeed, support for SqlServerCE is then a great thing to have

So far I think SqlServerCE support is doable, though as SqlServer CE is somewhat limited, some features aren't available when using SqlServerCE, but that's not that much of a problem I think.

Otis wrote:

I wonder if it would be possible to build a special CF remoting/web services facade that translated between CF entities/collections and "normal" ones. Is the CF framework even installable outside of CE device?

Only on an emulator . You can recompile code for the CF on .NET though (with some small exceptions)

You should be able to read the XML for an entity from a webservice, and re-instantiate an entity on the CF, work with it, and send it back. As what's transported is XML, it should be possible to receive the XML at the server again and re-instantiate an entity from it and save it to the db for example.

So you're saying that the ReadXML and WriteXML methods may/will be able to serialize and deserialize entities from either platform? Not trying to pin you down, but that would be a fantastic solution. Would that extend to collections, etc as well?

Otis wrote:

So indeed, support for SqlServerCE is then a great thing to have

So far I think SqlServerCE support is doable, though as SqlServer CE is somewhat limited, some features aren't available when using SqlServerCE, but that's not that much of a problem I think.

Definitely! I agree with Devildog that having access to the local data store is very important. That would be the minimum requirement to building a "Smart Client" which is how many business data-oriented CF apps will be built.

Jeff...

jeffreygg wrote:

Otis wrote:

I wonder if it would be possible to build a special CF remoting/web services facade that translated between CF entities/collections and "normal" ones. Is the CF framework even installable outside of CE device?

Only on an emulator . You can recompile code for the CF on .NET though (with some small exceptions)

You should be able to read the XML for an entity from a webservice, and re-instantiate an entity on the CF, work with it, and send it back. As what's transported is XML, it should be possible to receive the XML at the server again and re-instantiate an entity from it and save it to the db for example.

So you're saying that the ReadXML and WriteXML methods may/will be able to serialize and deserialize entities from either platform? Not trying to pin you down, but that would be a fantastic solution. Would that extend to collections, etc as well?

That's the goal, yes. To be able to write XML on the server, send it to the client on CF, which re-instantiates entities from the XML, works with them, you can store them locally if you want, read them back later, write XML on the client and send it to the service/server which then rebuilds entities from the XML and writes them back into the main system.

As everything is already in place, I just have to make sure the code runs on CF . There is a potential problem with Attributes on properties, which aren't readable on the CF, so hte XML from the CF client to the service will be a bit bigger (as it can't detect XmlIgnore attributes etc.)

Otis wrote:

So indeed, support for SqlServerCE is then a great thing to have

So far I think SqlServerCE support is doable, though as SqlServer CE is somewhat limited, some features aren't available when using SqlServerCE, but that's not that much of a problem I think.

Definitely! I agree with Devildog that having access to the local data store is very important. That would be the minimum requirement to building a "Smart Client" which is how many business data-oriented CF apps will be built.

. I now hope I can trick the compiler to compile the normal generated code for the CF using a set of dummy classes. This approach works well with the ORM support classes. The SqlServer DQE needs some porting as the insert query builder has to build 2 queries now, one scalar one for @@IDENTITY and a normal one, as SqlServer CE doesn't support batching.

Otis wrote:

There is a potential problem with Attributes on properties, which aren't readable on the CF, so hte XML from the CF client to the service will be a bit bigger (as it can't detect XmlIgnore attributes etc.)

Hmm. I can read attributes off properties with the following code. Isn't this what you are looking for?

        [AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]
        public class MyAttribute : Attribute
        {
            public readonly string Message;
            public MyAttribute(string s)
            {
                this.Message = s;
            }
        }

        [MyAttribute("Hello World!")]
        public int Foo
        {
            get { return 0; }
        }

        private void AttributeTest()
        {
            PropertyInfo[] properties = this.GetType().GetProperties();

            foreach (PropertyInfo pi in properties)
            {
                MyAttribute[] attributes = (MyAttribute[]) 
                    pi.GetCustomAttributes(typeof(MyAttribute), false);

                if (attributes != null && attributes.Length == 1)
                {
                    MyAttribute ta = attributes[0];
                    MessageBox.Show(ta.Message);
                }
            }
        }

Oh, and just to chime in on this discussion: having support for the ORM support classes and a SqlCe DQE would be wonderful as I will be storing entities locally in SqlCe and using my own binary synchronization protocol. I can also see myself using XML serialized entities in the future though.

wojo wrote:

Otis wrote:

There is a potential problem with Attributes on properties, which aren't readable on the CF, so hte XML from the CF client to the service will be a bit bigger (as it can't detect XmlIgnore attributes etc.)

Hmm. I can read attributes off properties with the following code. Isn't this what you are looking for?

        [AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]
        public class MyAttribute : Attribute
        {
            public readonly string Message;
            public MyAttribute(string s)
            {
                this.Message = s;
            }
        }

        [MyAttribute("Hello World!")]
        public int Foo
        {
            get { return 0; }
        }

        private void AttributeTest()
        {
            PropertyInfo[] properties = this.GetType().GetProperties();

            foreach (PropertyInfo pi in properties)
            {
                MyAttribute[] attributes = (MyAttribute[]) 
                    pi.GetCustomAttributes(typeof(MyAttribute), false);

                if (attributes != null && attributes.Length == 1)
                {
                    MyAttribute ta = attributes[0];
                    MessageBox.Show(ta.Message);
                }
            }
        }

thanks for the code! I use propertydescriptors, which don't have the ability to offer you the attributes on CF, but this of course works! cool!

Otis wrote:

thanks for the code! I use propertydescriptors, which don't have the ability to offer you the attributes on CF, but this of course works! cool!

No prob. You'll see this trend often in the netcf, that is taking something out because there was another way to do it to save space in the runtime. It's annoying, especially when the only way they leave requires a lot of workarounds and code.

But as you've also have seen already, some things are missing altogether. Luckily we have the OpenNETCF project, and that helps out a lot.

Welcome to the world of the (sometimes very) compact framework

wojo wrote:

Otis wrote:

thanks for the code! I use propertydescriptors, which don't have the ability to offer you the attributes on CF, but this of course works! cool!

No prob. You'll see this trend often in the netcf, that is taking something out because there was another way to do it to save space in the runtime. It's annoying, especially when the only way they leave requires a lot of workarounds and code.

yeah, especially because there is very little documentation (IMHO) what to use instead. I can understand they picked just 1 overload of a large set of overloads, but this is pretty obscure.

But as you've also have seen already, some things are missing altogether. Luckily we have the OpenNETCF project, and that helps out a lot. Welcome to the world of the (sometimes very) compact framework

Yeah OpenNETCF is great, it already helped me create GUID's for example. Another thing I really miss is XPath (had to create a lame search routine to mimic hte usage of XPath) and remoting. I can understand that you have to save ram etc, but the SOAP formatter assembly as a whole is 128KB. Cut out some fluff and you're there... . Oh well..

Why doesn't this (*#&$(@$&@# SqlServerCE support output parameters!

I hope I can fake it with an extra input parameter without a value, in which I later on place the @@IDENTITY value for the field - param sync.

Is there a way I can test CF.NET code on SqlServer CE in VS.NET? A link to a guide to get started is enough.

Otis wrote:

Why doesn't this (*#&$(@$&@# SqlServerCE support output parameters!

I hope I can fake it with an extra input parameter without a value, in which I later on place the @@IDENTITY value for the field - param sync.

Hmm, haven't tried this before. Let us know how that goes.

I did read in the SQL Server CE Books Online under the "Commands" section this, though:

"SQL Server CE supports parameterized queries in which parameters are delimited with the question mark (?) character; however, named parameterized queries and output parameters for queries are not supported"

Otis wrote:

Is there a way I can test CF.NET code on SqlServer CE in VS.NET? A link to a guide to get started is enough.

If you start a Smart Device project, and choose Pocket PC / Windows Application (at least that's what I target) you should have a project that by default, will run with F5 in the Pocket PC 2002 emulator. I don't remember exactly, but I think I had to install the Pocket PC 2003 emulator after the fact from here:

http://msdn.microsoft.com/mobility/downloads/sdks/default.aspx

It's under "Software Development Kit for Windows Mobile 2003-based Pocket PCs." There are some other resources there on emulation, too.

Then if you add the System.Data.SqlServerCe reference, VS.NET 2003 will automatically install the SqlCe 2.0 runtimes to the device on deployment.

Should be as easy as that! You'll have a fully functioning device in the emulator with the netcf and SqlCe.

Note: you can't create the SqlCe .sdf database files on the desktop (yet). That's in VS.NET 2005, but for now you'll have to use DDL on the device to create the database, or use the built in query analyzer or something like Resco Query Analyzer.

wojo wrote:

Otis wrote:

Why doesn't this (*#&$(@$&@# SqlServerCE support output parameters!

I hope I can fake it with an extra input parameter without a value, in which I later on place the @@IDENTITY value for the field - param sync.

Hmm, haven't tried this before. Let us know how that goes.

I did read in the SQL Server CE Books Online under the "Commands" section this, though:

"SQL Server CE supports parameterized queries in which parameters are delimited with the question mark (?) character; however, named parameterized queries and output parameters for queries are not supported"

As a matter of fact, I had to add code to fake it already for ms access . Normally, I add an output parameter, which gets filled by the scalar query which grabs the sequence value. The output parameter isn't used in the quer itself (no batching). Access didn't allow an output parameter which wasn't used in the query, so I had to use input parameters there, anyway. I hope SqlServerCe tolerates an input parameter which isn't used in the query, but I don't see why they would add code to test on that

I now have the ORM Support classes and an SqlServerCE DQE compiled for the CF. I added code based on your propertyinfo code to make sure it could read Browsable (which I added as a dummy class attribute) and XmlIgnoreAttribute and I think all works out fine .

Next stop: generated code compilation! .

Otis wrote:

Is there a way I can test CF.NET code on SqlServer CE in VS.NET? A link to a guide to get started is enough.

If you start a Smart Device project, and choose Pocket PC / Windows Application (at least that's what I target) you should have a project that by default, will run with F5 in the Pocket PC 2002 emulator. I don't remember exactly, but I think I had to install the Pocket PC 2003 emulator after the fact from here:

http://msdn.microsoft.com/mobility/downloads/sdks/default.aspx

It's under "Software Development Kit for Windows Mobile 2003-based Pocket PCs." There are some other resources there on emulation, too.

Then if you add the System.Data.SqlServerCe reference, VS.NET 2003 will automatically install the SqlCe 2.0 runtimes to the device on deployment.

Should be as easy as that! You'll have a fully functioning device in the emulator with the netcf and SqlCe.

Note: you can't create the SqlCe .sdf database files on the desktop (yet). That's in VS.NET 2005, but for now you'll have to use DDL on the device to create the database, or use the built in query analyzer or something like Resco Query Analyzer.

As long as I can get SqlCe started on the emulator I think I can get it going. Thanks for the info!

Ok, Adapter generated code (VB.NET/C#) compiles, using a normal SqlServer project.

Will now try SelfServicing. It should be pretty straight forward, with a possible hickup in property descriptor land, but that's about it. Then the big 'but does it work?' begins Stay tuned.

I for one am looking forward to netcf (sqlce) support. I have put my project on hold, for now, to enable use of this.

Ready and waiting.

Thanks.

Hameed wrote:

I for one am looking forward to netcf (sqlce) support. I have put my project on hold, for now, to enable use of this.

Ready and waiting.

Thanks.

I'll upload the first bits later today, for adapter (selfservicing code has to be ported still). I've not yet wrote a single line of code to see if it actually works, the code compiles though. Tomorrow I'll port selfservicing code over, which should be pretty easy.

For the few who can't wait .

Go to the customer area and download: - task performer archive - runtime library archive - templates archive

The CF/CE files aren't distributed with the new installer yet, as they first have to be tested. Again: selfservicing doesn't have compilable code yet, Adapter has.

Required: the latest official release of OpenNETCF