Latest Posts
We recently needed the ability to do most-recently-updated data caching in our
Solution Family products. Since the products use the OpenNETCF
ORM Framework, it only made sense to update the framework itself to include events
that fire whenever an Insert, Update or Delete occurs. In fact I added Before
and After versions for each. While I was at it, I also added a full complement of
virtual On[Before|After][Insert|Update|Delete] methods to the DataStore base, allowing
DataStore implementers to hook into the process as well. I'm thinking I'll use
those at some point in the future to add some form of Trigger capabilities.
Managed Code in the Embedded World
I'm trying my hand at making using some of our stuff a bit easier. Today I burned
some time trying to understand the project template infrastructure and the result
was the creation of a couple VSIX files for installing IoC templates into Visual Studio.
Right now it only supports desktop projects (IoC supports Windows Phone, Mono for
Android, Monotouch and Compact Framework). I've also not figured out how to actually
deploy the IoC and Extensions binaries with the templates, so when you create your
project, the References section will contain IoC references, but they'll be broken.
Still, as a first cut it greatly simplifies setting up a new IoC UI (SmartClientApplication) or
IoC Module project.
You can install the templates in one of three ways:
Managed Code in the Embedded World
Ages
ago I created an SDK that allows you to extract device CAB files and create a
replacement for wceload if
you wanted (we used this on a couple customer applications). We also tried to
sell it as an experiment in "value-based
pricing". Well the experiment showed, largely, that people would pay the
minimum and very, very rarely come back and pay anything more so either it was of
low value, or people are just cheap.
At any rate, I don't feel like maintaining it internally any longer so it has become
yet another project that I've open sourced for the community at large. The
full download is now available over on Codeplex.
Managed Code in the Embedded World
I just got an email in the Support inbox over at OpenNETCF asking about the libraries
support (or really lack thereof) for Wireless Networking in Windows Embedded Compact
7 (rolls off the tongue, doesn't it?). While this is a question about a specific
feature of the SDF, it really opens up the broader question of what our plans are
for the future of the whole product. In fact you could say it really opens up
the question on what our general company plans and philosophy are.
First, let's address this specific issue, as it deserves answering and has a little
bit of a back story leading to a minor rant which is always fun.
The SDF supports an object model for wireless networks that is based around the Wireless
Zero Config (WZC) API. Microsoft introduced WZC in CE 5.0 (IIRC) in an attempt
to "standardize" the way the platform and apps would communicate with the wireless
drivers, since NDIS doesn't really have any specification for a lot of the wireless
properties. While I applaud the spirit, WZC is convoluted at best, and was definitely
not designed to make the life of someone who has to use P/Invoke to communicate with
it any easier. Still, it was some sort of standardization so we rolled up our
sleeves and created a managed interface for it.
I'll readily admit that what we ended with isn't ideal, but I'm a fierce self critic
and I rarely think what we do is as good as it could be. Still it provided a
programmatic interface for something that a *lot* of people wanted and that Microsoft
had not implemented in managed code.
Well with Compact 7 (I'll just call it CE7) Microsoft decided that WZC wasn't the
way to go, but instead Native WiFi was. Painfully they didn't follow a sensible
"deprecated but supported" track for WZC and support side-by-side, they just dropped
WZC support altogether. That meant that we could not interface with a wireless
adapter under CE7 using our existing code base at all - it was a flat-out break.
To make things worse, Microsoft went radio-silent for about 2 years (and still counting
- yes I'm looking at you Redmond!) on what, if any, future the Compact Framework,
or CE for that matter, might have. The original WZC work was probably 4-6 weeks
of development and it required that we buy several devices for testing. Believe
me, it was a real pain in the ass. Do we (more specifically do *I*) really feel
like doing that all again for the Native WiFi interfaces? If I do, where do
I get a CE7 device with WiFi support? If I do all of that work, what's the ROI
if Microsoft kills the Compact Framework? What's the ROI if they revive it and
implement Wireless themselves?
It's really difficult to answer those questions, and we're not the only ones who are
wondering these things. I can say, though, that we've very recently decided
that yes, we will continue to do both support and new development
for the SDF. What that new development will entail I can't say. Not because
it's some big secret, but because I can't make those plans until Microsoft tells us
their plans (and they haven't). If they decide to release a new version of the
Compact Framework, I'd like to not have a load of functionality duplication between
it and the SDF.
So, is the SDF a dead product? No. We will continue to support it and
have plans for feature additions. We just don't know exactly what those features
will be or when they will be written (confidence inspiring, I know).
Will we provide Wireless support for CE7? If Microsoft does not, then yes, we
will. Again, we don't know if they will or not. If they did, we don't
know when that would be. Ideally, though, programming for WZC and Native WiFi
should be the same, so if they don't do it, we'll add support that looks and feels
just like what's in the SDF today. If they do add it, I'd be inclined
to update our object model to match theirs (keeping the old stuff for compatibility
though).
Don't read too much into this. Yes, I'm optimistic about the Compact Framework
and Windows CE Windows Embedded Compact but I've been using them
for over a decade and I've based a whole lot of my knowledge, business and life on
them. I almost have to be optimistic. But let's face it, CE and the CF
are still great tools for delivering products. We're still shipping products
based on them. Still doing new development and new installs. Still writing
proposals for them.
Yes, we've tested the waters with Android and iOS. We've even delivered finished
products for them both, but using those tolls only reinforced my feelings about the
strength and possibilities of the CF and CE and we're still committed to using and
supporting them.
Managed Code in the Embedded World
I've been working in the Windows Embedded space for over a decade now, and I must
say it's a far different picture today than it was in years past. That's not
a jaded nostalgia either - Windows Embedded used to have a real annual conference
at nice venues in Las VEgas. We has good speakers and great content.
The teams in Redmond shared loads of info about what was going on and what was coming
down the pike. Teams cared about what they were doing and what their customers
wanted.
Slowly, though, it seems to have atrphied to the state that it's in today. I
know of no one using Compact 7 in an actual product. The Compact Framework hasn't
had an update in something like 4 years and there is absolutely no word at all what
its future might be. The tools required to do development for non Windows Phone
devices are no longer available unless you purchase a full (expensive) MSDN subscription.
I can usually count the number of questions that get asked in public forums and places
like Stack Overflow in a week on two hands - sometimes just one.
Today I got what had to be one of the most telling things I've seen though.
A sign that the people is Redmond just don't care any longer either. For years,
Microsoft has sent out a monthly embedded newsletter - the Windows Embedded InfoBlast
- and while the quality of the contents has been in the same slow decline
as the rest of the industry, the one I received today just pegged the "I no longer
give a shit" meter. This is exactly how it looks in Outlook for me:
Obviously either no one cared enough to even look at that before it went out, or if
the did they didn't care if anyone actually read it. Looking at it is like looking
into the sun, but without the benefit of the warmth on your face.
Managed Code in the Embedded World
In my push to get our fundamental libraries up and working on Mono for Android we've added
support for OpenNETCF Extensions and OpenNETCF
IoC. What that means is that now you can have a common code for a lot of
application infrastructure that works on the Compact Framework, the desktop, Windows
Phone, MonoTouch for iOS and Mono for Android. So you can now create a
single, common code base for your applications that includes data access, event aggregation,
dependency injection and inversion of control.
Get the latest code over on Codeplex.
Managed Code in the Embedded World
We've started doing work creating client applications for a few of our products to
run on Android and iOS devices. Since I'm a huge fan of code re-use, I took
the time this week to port the OpenNETCF.ORM over
to Xamarin's Mono for Android using
a SQLite backing store implementation.
The biggest challenge was that SQLite doesn't support TableDirect not ResultSets,
so it took a bit of code to get running. Still, it took only a day and a half
to get what I feel is pretty good support up and running. I've not yet tested
it through all of the possible permutations of queries, etc, but basic, single-table
CRUD operations all test out fine.
So now a single code base can work on the Windows Desktop, Windows CE and Android
(probably iOS and Windows Phone as well with very little work). If you're doing MonoDroid
work, give it a try.
Managed Code in the Embedded World
Occasionally I'm surprised at how old software never seems to really die off.
Take for example an old port I did of the zlib compression library to Windows CE.
Back in probably '05 I built the original sources for the Windows CE platform.
In '07 I created a managed wrapper for the library and some samples on how to use
that library. I put it on the web and then pretty much forgot about it.
Well when we migrated our web site to a new server, some old links died and this just
happened to be one of them (if you know of others, please let me know) and today I
got an email from someone asking if I still had the code. Sure, it wasn't the
day things went down, but it still means not only was someone looking for it, the
cared enough to email me and ask.
For those looking for it, it's got a new, hoipefully more permanent home on Codeplex: http://zlibce.codeplex.com
Managed Code in the Embedded World
Lately it seems that I'm been doing a lot of posts referring to "a customer".
Often they are different customers, but it really sounds impersonal, so in this one
I'm going to name names and point fingers - in a friendly way, of course.
Last week Nicolas emailed me to get some advice on the Visual Studio 2008 Forms designer
and the Compact Framework. Specifically he wanted to know if it's possible to
get a custom TabControl to be designable. My assumption is that either he's
inheriting from the stock version or they've created a fully custom control inheriting
from ContainerControl - I didn't ask because in either case the answer is simple:
it's not going to work in the designer.
I told him that it won't work, but in retrospect I feel I've short-changed him a bit.
As a developer, I like to hear a bit more than an "abandon all hope, ye who sail here
for there be sea monsters" kind of response. Why doesn't it work? More
importantly, what are my options for a workaround?
In this case it's interesting to note that even if he could get the designer to work
for this control, I'd recommend that he not do it.
And they why to that recommendation is far more interesting.
So, Nicolas, here's the longer answer to your question.
First, you have to understand that the Studio Designer is very, very brittle.
Any little quirkiness tends to send it into fits, and once broke you often spend large
amounts of time unloading things, resetting the toolbox, restarting Studio or even
restarting the PC. This is a huge time drain, so avoiding situations that break
the designer is the first order of business.
Getting the designer working for a CF component is even worse. CF controls often
make use of things that the desktop doesn't even have, which the designer really hates.
You also have to build the Controls for both versions of the CF (for Nicolas this
is important since, at least last time I was with his team, they had versions of the
application targeting CF 2.0 and CF 3.5). A control built against CF 3.5 will
never show up in the designer of a CF 2.0 project. There's also a major bug
in the designer that limits CF 3.5 controls that I've
written about before.
For designer support you also have to maintain an XMTA file and often end up having
condition compiler statements which really make the code less readable. Workarounds
for most of these issues exist. You can create separate set of "designer" assemblies
that provide only stuff for the designer and minimal actual control logic. The
problem with this is that you then have to maintain these things, which sucks up developer
time that should be spent actually solving your business problem.
You can't create a desktop assembly and use it for the designer because the designer
will then suck in the full .NET framework as a reference and attempt to deploy that
to the device when you want to debug.
So if the designer is so brittle and worthless, what's a developer to do? Well,
my general attitude is to provide "support" only for basic Controls, and by "support"
I mean the inherent capability of the designer to show a box with the location and
bounds of your control. No rendering. No styling. No collection
editing.
Really the designer's primary use for me is to aid in basic layout. I need to
put a Control on a Form, set it's location and Size and that's it anyway. Anything
else is done via code, and there's nothing wrong with this. Embrace it as how
you must work and your life becomes much simpler.
That's all well and good for a simple Control, but what about a container like Nicolas
is after? His team would like to be able to drop on a Tab control and design
each individual Tab, right? So what are they to do?
Well, I think they're looking at the problem wrong to begin with. I don't blame
them, people have been looking at this wrong for some time, and the simple existence
of the TabControl tend to push people to look at it wrong. In general, my recommendation
is to not use the TabControl in the first place.
First of all, it's 2011. That ass-looking TabControl would have been ok back
in 1995 (if the devices had existed then) since it looks just like the ass-looking
Windows 95 interface.
It's was an ok solution in 2000 when these devices were new and people thought of
them as just "mini PCs" so extending the desktop paradigm to the device was what we
did. Yes, we wished we could do a little more to make it pretty
by adding icons and custom drawing, but it worked and users really didn't expect anything
more.
But it's 2011. Users don't use a stylus if they can avoid it. They know
an elegant UI when they see one because they've been using a smartphone. Just
because they have no choice in the app they use (this is an LOB app, so the user is
locked in) is no excuse to not deliver something that is actually nice to use.
The TabControl does not meet that. It's tiny, it scrolls weird, and it's ugly
with no options to make it non-ugly. Plus it's Tab motif. Name the
last mobile app you used on a phone that used tabs. That's what I thought. Abandon
the piece of crap.
So what would I use? Obviously this will be subjective, as it's what I would
personally do given a blank slate. Nicolas is trying to put something into an
already-existing, very large code base, so his mileage may vary, but I'm betting it
won't be too bad, and implementing this might actually do a lot toward getting other
gains they really need like better transition time between views.
I'd start using the OpenNETCF IoC
project. I'd split each of the existing "tabs" into individual SmartParts,
which are now fully designable since they're just UserControls. So there you
are - the designer requirement is solved. I'd then place on the Form a pair
of DeckWorkspaces. One would display the "selected" view and the other would
replace the "tabs" of old with buttons or clickable images that would be used to select
the current view. It would look something like this in the designer for the
Form:
And then the SmartPart that goes into the bottom workspace might be something like
this in the designer (well it would probably be a bit different, but you get the idea):
See, the designer works. It meets the business requirement that it provides
a "tab-like" capability where the user selects an item across the bottom and the upper
view changes. But now it's not just usable with a stylus but it's also likely
to be usable with a finger (gasp!) and aesthetically it doesn't make
my want to poke my own eyes out. It's a win-win. Plus now you can lazy-load
the views *on demand* rather than loading up every damned control on every tab when
the Form is brought up, so the user is going to be pleasantly surprised there too.
Oh, and now it's easy to change out "tabs" based on user rights or workflow and probably
other benefits that I'm not thinking of.
Occasionally we've got to break out of the "what we know" and the "what we've always
done" routine and look out at the horizon. By doing so we can often make some
simple changes and make things easier for both the developer and the user, and that
is how we make progress.
Managed Code in the Embedded World
I've published new updates to our MTConnect projects on Codeplex. Both the MTConnect
SDK and the VirtualAgent have changes
and for detailed info take a look at the change logs in the Source tabs on the project.
Here's a high-level list of what I think the important additions are:
-
I've added a fully working reference implementation of an MTConnect Adapter for Okuma
THINC controllers (full source is included). If you have an Okuma machine with
a THINC-supported controller on it, you now have a simple agent and adapter you can
drop onto the machine to start publishing data immediately. I hope to find time to
put together a reference implementation for Fanuc FOCAS controllers. If you're
interested or in need of that support, let me know and we can discuss prioritizing
it and the features you need.
-
I've added support for SHDR adapters. At the [MC]2 conference in Cincinnati
there was concern that once you selected an Agent technology (either ours or the reference
MTConnect C++ Agent), then you were locked in to creating Adapters only for that Agent.
That is no longer the case. Our Virtual Agent now can easily consume data from
your existing C/C++ Adapters written against the reference Agent. No changes
are required in your existing Adapters at all.
If you have any questions on implementation, etc, feel free to contact me. For
more info on our entire line of MTConnect products, take a look at our
web site.
Managed Code in the Embedded World
Back in May 2008, I wrote a blog post about checking
for Win32 methods. I was recently reminded of this when a customer emailed us
about a scenario that exactly matched the intended use case.
The customer was using the Smart Device
Framework with a Windows CE 5.0 device and was receiving a MissingMethodException
"Can't find an Entry Point 'xxx' in a PInvoke DLL 'yyy'". The exception message
is detailed enough to explain the situation -- since Windows CE is modular, whoever
created the OS image had not added a required component, resulting in the native functions
to be missing from coredll.dll. This is not an uncommon scenario in the Windows CE
world.
Below is an example of how you can gracefully handle calling the PlaySound function
from coredll.dll even on devices that don't support the function. The important
part is the call to Device.Win32Library("coredll").HasMethod("PlaySound").
This is return false if coredll.dll does not exist or if coredll.dll does not export
the PlaySound function. Of course, you could raise a PlatformNotSupportedException or
try another mechanism for playing the sound file instead of just returning without
calling the native PlaySound function. The important point is that you should code
in a way that can handle scenarios where the native function is not available and
adapt accordingly.
Imports System.Runtime.InteropServices
Imports OpenNETCF.Reflection
Partial Public Class MainForm
Friend Class NativeMethods
Private Const SND_ASYNC As Integer = &H1
Private Const SND_FILENAME As Integer = &H20000
Public Shared Sub SafelyPlaySound(ByVal soundFile As String)
If Not Device.Win32Library("coredll").HasMethod("PlaySound") Then
Exit Sub ' Function is not exported so we silently return
End If
' Coredll exists and the PlaySound function has been exported
' so we can safely make the P/Invoke call
PlaySound(soundFile, IntPtr.Zero, SND_ASYNC And SND_FILENAME)
End Sub
_
Private Shared Function PlaySound(ByVal szSound As String, _
ByVal hMod As IntPtr, _
ByVal flags As Integer) As Integer
End Function
End Class
End Class
Last week we quietly launched a fantastic new promotion for our Padarn
Web Server product:
Padarn is a lightweight, single-purpose web server that supports a growing subset
of ASP.NET. It is written entirely in C# and can be used as stand-alone web server,
or embedded into an existing application. Padarn can be used to create elegant, data-driven
web sites using SQL Server Compact Edition, or interface with a whole myriad of hardware
peripherals, such as web cams, sensors, controllers, etc.
If you would like more information on Padarn, please send an email to padarn@opennetcf.com.
Note: This blog post only applies to Smart Device Framework Standard or Professional
Edition customers.
>
If you open the SDF Public Source solution that ships with Smart Device Framework
2.3 and then build the source, you'll come across the following error:
Friend access was granted to 'OpenNETCF,PublicKey=...', but the output assembly is
named 'OpenNETCF, Version=2.3.0.21, Culture=neutral, PublicKeyToken=null'. Try
adding a reference to 'OpenNETCF,PublicKey=...' or changing the output assembly name
to match.
(Note that I've replaced the actual public key with ellipses in the above. You will
see an extraordinarily long hexadecimal number in your errors list in Visual Studio.)
The easiest way to remedy this is through a quick search & replace. Hit Ctrl-H to
bring up the Find & Replace window. In the Find what text box, enter
the following:
,PublicKey=00240000048000009400000006020000002400005253413100040000010001002beeba3
bfe7c548e085cffb8c2b6fd61ddd02b06d70864bb7de8bb22473edf5ab4b2196ff98e232c3e87f11fd
7986b743d5d3fdd6ecaf624bacfed116e1cefa50cd652365371d0ebd2702eb1084fed46df79ac0f59f4
d66c547918613d56dcf106843f3458516d3cd26f057a346d9f645fc24a7410a095c754835916e13cdbe
Make sure the Replace with text box is empty and the Look in combobox
is showing Entire Solution. Click the Replace All button. When the search
& replace has completed, build the solution again and it will succeed.
If you wish to do this manually (you may only want to use 1 or 2 of the 16 projects),
you will need to modify the AssemblyInfo.cs file for the following projects:
-
OpenNETCF
-
OpenNETCF.Configuration
-
OpenNETCF.Net
-
OpenNETCF.Windows.Forms
>
Today, we released Smart Device Framework
2.3. This is the long awaited release of the Smart Device Framework for Visual
Studio 2008.
It's been a painful path to get to this point, what with contending with frustrating
bugs in Visual Studio 2008 forms designer and all, but we finally got there. Thanks
for you patience and understanding.
Along with the new version is a new naming convention. We've dropped the name Smart
Device Framework Extensions for Visual Studio with its Standard and Premium editions.
Instead, say hello to Smart Device Framework Standard Edition and Professional
Edition. Be sure to check out the new feature
matrix to find out how each edition differs.
We've got some pretty cool stuff features in the libraries, notably OpenNETCF.Core which
contains a dozen or so extension methods for common scenarios, as well as OpenNETCF.Net.Mail,
for sending mail via SMTP directly from the device -- this eliminates the need to
configure a mail account on the device.
When you reference an assembly compiled against .NET Compact Framework 2.0 in a project
targeting .NET Compact Framework, it's quite likely you will receive a number of ResolveAssemblyReferences warnings,
similar to this:
ResolveAssemblyReferences:
Consider app.config remapping of assembly "System.Windows.Forms, Culture=neutral,
PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "2.0.0.0" [] to
Version "3.5.0.0" [C:\Program Files\Microsoft.NET\SDK\CompactFramework\v3.5\
WindowsCE\System.Windows.Forms.dll] to solve conflict and get rid of warning.
This warning occurs when the compiler has loaded the .NET Compact Framework 3.5 base
class libraries (BCLs) and the referenced assembly, but the metadata contained in
the referenced assembly references the .NET Compact Framework 2.0 BCLs.
To remove the warnings you can add an App.Config to your project and redirect the
assembly bindings from the 2.0 versions to the 3.5 equivalents. Below is an example
of the XML required in the App.Config to redirect the 2.0 version of System.dll to
the 3.5 version.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentassembly>
<assemblyidentity name="System" culture="neutral" publickeytoken="969db8053d3322ac" />
<bindingredirect newVersion="3.5.0.0" oldVersion="2.0.0.0" />
</dependentassembly>
</assemblybinding>
</runtime>
</configuration>
You will need to add a dependentassembly element for each of the ResolveAssemblyReferences
warnings that you receive.
Make sure the Build Action property of the App.Config is set to Content and
the Copy To Output Directory property is set to Only if newer. Then,
rebuild your solution and the warnings should not appear.
There's been a lot of internal discussion today on how to leverage C# 3.0 features
without requiring .NET Compact Framework 3.5. Mark has the low down on using extension
methods with a little compiler misdirection hack.
The discussions kicked off because I discovered that you can use lambda
expressions with .NET Compact Framework 2.0 projects in Visual Studio 2008. I
even twittered about it yesterday. (Note: it didn't take me too long to realize it's
not a bug, but due to Visual Studio 2008 using the C# 3.0 compiler.) Code
like the following just works -- no hacks required:
delegate double PowerOf(double x, double y);
static void Main()
{
PowerOf pwr = (x, y) => Math.Pow(x, y);
double result = pwr(2, 3);
}
If you are using Visual Studio 2008 and still need to target .NET Compact Framework
2.0, the little things like this go a long way to creating and maintaining reusable
code.
Over the last few months we've been working hard to attain the Gold Level partner
status in the Microsoft Partner Program and I'm extremely pleased to say that we've
done it! For our customers, this is an assurance that by choosing to work with OpenNETCF
products and our consultants, you really are choosing a high calibre company.
Massive amounts of credit for Mark for
driving this internally. Good job!
The next Smart Device Development Chat will take place on MSDN at 10am PST on Wednesday,
July 16.
Please join experts from the Windows Mobile, Windows CE, SQL Server CE and .NET Compact
Framework communities in a chat around application development for smart devices.
These chats are a great opportunity to have your questions answered by experts from
around the world.
Add
to Calendar
If you cannot attend the MSDN Chat, there is a permanent chat room available on the web and
via IRC (irc://irc.freenode.net/mobiledev).
Engage with your peers online today!
A little later than I intended, but here is the transcript to Smart Device Development
chat from May 13, 2008: Read
it here
I was browsing around over lunch when I came across an upcoming title from Wrox that
I thought might be interesting to someone out there.
The book, being writing by Samuel Phung of ICOP,
is titled Professional
Microsoft Embedded CE 6.0. A book like this is sorely needed as most of the knowledge
exists primarily in the embedded newsgroup or scattered around in a handful of blogs.
The 20-chapter book will cover everything from creating an image to development in
C# and VB.NET, as well as C++ and is scheduled to be released in November. Wrox have
made a number of chapters available through
their Wrox First subscription service.
