Unfortunate behavior of CF2SP1 cab install

  • Thread starter Thread starter Ilya Tumanov [MS]
  • Start date Start date
I

Ilya Tumanov [MS]

Thanks for reporting this, I was not aware of this case.
Thanks for reporting this, I was not aware of this issue. I'll see if I can
fix it for next version of NETCF.



Unfortunately, registry entry is not particularly reliable even not counting
this one, which is why nether VS not Cgacutil.exe uses it.



More reliable way to detect NETCF from native code would be to enumerate
\windows\mscoreeX_Y.dll and grab version from this file.

Managed code should use System.Environment.Version to check it's running
under correct version of NETCF.



For automatic installer you can also eliminate user from the equation by
running installation silently.


--
Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
On WM5 device with CF2.0 version 2.0.5238 installed I installed version
2.0.6129 cab (SP1) by clicking on it directly on the device file system. It
will prompt:
"The previous version of Microsoft .NET CF 2.0 will be removed before the
new one is installed. Select OK to continue or Cancel to quit."

Click cancel. The cab does not get installed. This is confirmed via
cgautil.exe which gets replaced by new CF installs.

However, now the registry setting is displaying 2.0.6129 where it was
2.0.5238 before.
(Hkey_local_machine\Software\Microsoft\.NETCompactFramework)

This is a bit of an issue for me because I have an Autorun installer that
uses this registry setting to detect versions and decides if it should
install the CF2SP1 cab or not. If the user clicks cancel in the above
scenario, and runs the installer again, it will not even attempt to install
the new cab because the registry is lying to it by saying 6129 is installed
when it's not.

I have workarounds I can do, that's not my issue in this post, but I believe
the proper behavior for the CF2 SP1 cab would be to put the registry version
setting back to where it was when clicking cancel in this scenario. After
all, cancel should mean cancel.

Tim
 
Thanks. Question about silent install of CF 2.0SP1: When installing it
manually (clicking on cab), it prompts for a soft reset at the end. In
silent mode, of course, that doesn't show. I would have to put up my own
screen or dialog for the reset. Is it really necessary to do the soft reset?
There is no such prompt for reset in manual install in WM2003, what is it
about WM5 that makes a reset necessary?
 
Perhaps I'm missing something, but with a WM5 device that comes with CF
1.0.4292 in ROM and I install CF2SP1, System.Environment.Version does not
pick up on the new version of CF2. It still reports 1.0.4292.
 
It reports what the app is running against. You have CF 1.0 and 2.0
installed and the app was build for 1.0 and continues to use it. If you
want it to use 2.0, you need to either recompile it or add an app config
file to tell it to use 2.0 in compatibility mode. And at that point I'm not
sure what it will report, since it's still really running against a 1.0
interface. I'd be interested to see what it reports.


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
 
If you have an app.exe.config file with the appropriate 2.0 settings, the
app will report 2.0.

Hilton
 
So if you use reflection from that 1.0 app, you could in theory load
2.0-specific classes then. Interesting.

-Chris
 
In theory yes, but I haven't managed to - probably user error. I was hoping
to use the new Hardware Keys class and some others which sure would be
interesting as you say. I wasn't able to spend too much time on it.

Some file ops run a lot faster when running 2.0 (using the config file), but
the app is still written and compiled for 1.0. BTW: The CLR output we get
uses "System.Environment.Version" and it reports 2.0.6129.0

Hilton
 
Back
Top