No-Touch deployment - IEExec - Duplicate Entries in Assembly Cache - Strongly Typed Datasets - Inval

[Paul Linhardt]

I've been struggling with a problem using No-Touch Deployment for 10
days now. Searching the newsgroups, I can see that people have been
experiencing parts of the problem, but I haven't seen any posts about
my particular circumstances.

I have a client/server database application. Both Client & Server are
running .NET Framework 1.1.4322. The client is a VB.NET winform
application. On the server, I run a VB.NET Web Service that accesses
a MS ACCESS database and returns Strongly Typed Datasets (STD). The
Web Service uses the SOAP serializer to convert the STDs into XML
(Marshal By Object) and my VB client app converts the returned SOAP
messages back from XML to STD objects. So far, so good.

My client/server application works perfectly and is humming along
until one day my boss suggests that wouldn't it be good if we
distributed the client application using No-Touch Deployment. I place
the client app on the server and run it from within Internet Explorer.
I start getting Exceptions when I run the client app:
"System.InvalidCastException: Specified cast is not valid".

The exceptions happen only with Web Service methods that return
Strongly Typed Datasets (Web Service methods that return untyped
Datasets or other types of data work fine).

Every now and again, I compile a version of my client app that works.
If I recompile again with no changes, the new version doesn't work. A
version of myClientApp.exe that works once, always works. A version
that doesn't work, I can usually eventually get working eventually by
emptying various caches, restarting the server, etc. Once I get the
..exe working once, it continues to work. I conclude that it's not my
code that is the problem, but something about the assembly &
versioning.

Following various suggestions on newsgroups:

(1) I set the version number manually in AssemblyInfo.vb so it is not
automatically incremented with each compile
<Assembly: AssemblyVersion("0.0.1.2")>

(2) I set the http channel in the Web Service to make sure the SOAP
serialization is on:
<channel ref="http">
<serverProviders>
<provider ref="wsdl" />
<formatter ref="soap" typeFilterLevel="Full" />
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
<clientProviders>
<formatter ref="binary" />
</clientProviders>
</channel>

(3) Whenever I test the application, I clear out both the download
assembly cache (with gacutil /cdl) and IE's browser cache. I also
reset IIS from time to time.

NOW HERE'S THE WEIRD PART. By studying IIS's log, I see that whenever
I launch the app using No Touch Deployment, I see that IEExec is
making over 20 GET requests of the server. Even though my http
request is for myClientApp.exe, IEExec also tries to get
myClientApp.exe.config, myClientApp.DLL, myClientApp.resources.DLL,
etc. Most of these time out with 404 errors (no wonder it takes so
long to launch), but TWO GET requests actually succeed:
"myClientApp.exe" and "myClientApp.EXE" (spelled the same but with
different case sensitivity).

Checking the Global Assembly Cache with gacutil /ldl, I see that there
are that two copies identical copies of the assembly (same name &
version#). More useful is the IE InvalidExceptionError Window which
also shows that there are two copies of myClientApp assembly except
one has the lower case extension .exe and the other has the has the
upper case .EXE extension.

In this newsgroup, I found that it was documented that IEexec (used by
No-Touch Deployment) has a side-effect of loading two copies of your
assembly:

Subject: Assemblies deployed with IE are downloaded multiple times ?
http://groups.google.com/groups?hl=...-8&selm=OQT8XxHdCHA.1864%40tkmsftngp11&rnum=4

RE: No Touch Deployment.
http://groups.google.com/groups?hl=...NKAMy9lDHA.2416%40TK2MSFTNGP10.phx.gbl&rnum=2

For some reason, the fact that there are two versions of the assembly
(even though they are identical except the case-sensitivity of the
..EXE extension) seems to create a type-mismatch when client
application tries to deserialize the Strongly Typed Dataset in the
SOAP message.

Does anyone have any suggestions or idea of what is going on?

Thanks in advance,
Paul Linhardt
Paul_Linhardt@Lans mont.com <- remove space

 

[Chris Botha]

I'm not going to solve your problem, but here is my experience. I had a keen
interest in No-Touch deployment and eagerly played around with it for a
number of weeks.
I've abandoned the idea, mainly because of two reasons. My no-touch
deployment apps download/upload files from/to the server as well, thus
read/write to disk, and to allow this, each machine first has to be
configured to trust the server, so in any case the computer must be touched.
A second minor but irritating issue was that one of the apps had the IE
browser control on a form, this app took ages to no-touch deploy (users
impatiently staring at the screen, me too).
So, what I did, was to write my own crude deployment scheme. The app comes
in an install package, so must be installed on the computer (local install -
no more security issues, it can read/write). Every time the app starts, 1st
call the server sends back a bunch of assembly file names and dates, the
client app checks if that is what is on disk, and if not, loads them via a
web service and save them in a sub folder below the app's install directory.
Then the app launches a second exe (that comes with the install) and the
main app exits. The 2nd app copies the files from the sub-folder into the
main folder, exits, the user starts the main app again, which solves the
deployment issue. I have four apps like this running in the field now,
deploying successfully.

Maybe Microsoft realized it is not such a big hit too. I've seen a Whidbey
video and they now have the One Touch deployment built in. Basically it
installs the app (by clicking a hyperlink), and after that, the app will
automatically update via the internet from the server as well, no more
security issues, IE cache or the GAC, etc.

Darn, I've spent half of my evening writing this essay.

 

[Paul Linhardt]

Chris, thanks for your response. I'm not ready to throw in the towel
yet on no-touch deployment, but I see your point.

I've abandoned the idea, mainly because of two reasons. My no-touch
deployment apps download/upload files from/to the server as well, thus
read/write to disk, and to allow this, each machine first has to be
configured to trust the server, so in any case the computer must be touched.

Good point. The steps the client user must perform to give security
privileges to the browser & .NET are roughly equal in complexity to
what they would do in downloading a msi installer from an FTP site (of
an application which checks to see it has the right assemblies loaded
every time it executes).

A second minor but irritating issue was that one of the apps had the IE
browser control on a form, this app took ages to no-touch deploy (users
impatiently staring at the screen, me too).

I believe this delay is a result of dozen plus+ attempts by IEexec to
download variants of the filename specified (e.g.
myClientApp.exe.config, myClientApp.DLL, myClientApp.resources.DLL)
most of which result in http 404 errors.

I read somewhere that if I create a myClientApp.exe.config file and
give my application a strong name, I can avoid this excessive
downloading.

The server has to be reconfigured to permit downloading .config files.

And .config files cannot be cleared off the client machine (for
updates) with user installing gacutil (yet another nail in the coffin
for no-touch deployment).

=========

BTW, I made a surprising discovery this morning that my application
ran fine if I specified the upper-case .EXE version in browser URL
(e.g. http://myServer/myClientApp.EXE). No-touch deployment is
apparently case sensitive, however, the name of the file on my server
is 'myClientApp.exe' (lower case). It seems that IEexec is
downloading two identical versions of my application into the Download
Assembly Cache, but only the copy it renamed to have a .EXE (upper
case) extension works.

go figure.

-Paul

 

[Paul Linhardt]

In case anyone out there (besides Chris) is interested, I did find a
solution to the problem.

IEExec was loading two copies of the assembly into the download cache
(one ending in '.exe' and one ending in '.EXE'). The download cache
which hashes the name, date, etc. for identification decided they were
different even though the code was exactly the same. If I ran
'myClientApp.EXE' from a browser, it would run fine, but if I ran
'myClientApp.exe' I would get an InvalidCastException (somehow there
was a mismatch between the strongly typed dataset definition in the
client & web service).

Anyway, the solution was relatively simple and painless. I made my
client app assembly strongly named by adding a key pair:
http://msdn.microsoft.com/library/d...airforuseincreatingstrongly-namedassembly.asp

Strongly Named assemblies are only downloaded once by IEExec. Problem
solved.

-Paul