views:

279

answers:

1

Recently I had to troubleshoot a very strange issue with a fully-trusted InfoPath 2007 form at a customer site. The form is part of a records management application and users launch the form from within the application.

However, because the form is subject to frequent updates, we store a "master" copy of the form file on the customer's server. Whenever a user launches the form from our application, our software copies the form .xsn file locally to the Application Data folder, registers the local copy, and then launches it. Note that we don't use certificates, which is why we need to programmatically register the form each time it is launched.

This customer was having trouble launching the form from our application on one of their workstations. The logs indicated that the form couldn't be registered on this particular workstation (the form gets registered and opens fine on other workstations, all of which are running Windows XP).

Our software uses the InfoPath.ExternalApplication class to register and launch the .xsn file. The following VBScript reproduced the issue on the problem workstation:

Set infoPathApp = CreateObject("InfoPath.ExternalApplication")

'This line produces a pretty generic "Form template could not be registered" error,' 
'with absolutely no details as to *why* it could not be registered.'
infoPathApp.RegisterSolution "C:\Documents And Settings\All Users\Application Data\MyCompanysApp\MyCompanysInfoPathForm.xsn", "overwrite"

The really strange thing that I cannot for the life of me understand is that if I change

"C:\Documents And Settings\All Users\Application Data\MyCompanysApp\MyCompanysInfoPathForm.xsn"

to this:

"C:\Documents And Settings\All USers\Application Data\MyCompanysApp\MyCompanysInfoPathForm.xsn"

Then the form registers fine and the user can then open the form without any issues! Note that the only difference between the working and non-working code is that I changed "All Users" to "All USers" (capitialized the first "S" in "Users").

What the heck is going on here? Why would the casing of the filepath matter at all to InfoPath? What's more, why would the odd-cased version (with "All USers") work while the (obviously more correct "All Users") doesn't?

Also, for what it's worth, the "All Users" folder does appear as "All Users" and not "All USers" in Windows Explorer and in the file properties.

Update

I can only assume that something is different between the two workstations, but I'm at a loss as to what to look for in terms of differences. I realize I haven't provided a lot of details in the question (because I really have no idea what could be causing this behavior), but if anyone has any clues or possible causes, I'd be happy to hear them.

+1  A: 

This is a shot in the dark but:
Have you tried clearing the internet explorer cache and rebooting the workstation?
(In IE go to Tools->Internet Options, click Delete..., click Delete all...)

Also clear your InfoPath form cache while you are at it.

InfoPath saves form data in this cache and does not seem to clear it properly. This causes quite a few problems for me where an old file is opened from the cache when it shouldn't be. The change in the path may be causing a cache miss allowing your code to run properly.

If that doesn't work, the next question I would have would be:
Do you have this issue for all users on this workstation, or have you tried it with only one user?

oillio
I didn't know about the form cache (we don't do InfoPath development on a regular basis here - it's pretty much this one form). That's sounds pretty plausible actually, since we were updating this customer with a newer version of the form, and from my understanding of things, the previous version had worked fine. When I get a chance, I'll connect to the customer again and try out your suggestions. I've been at a complete loss with this issue. I'll +1 you just for the effort at this point ;) Thanks!
Mike Spross