Wow, this has been a tough one I closed this afternoon. The customer has developed a custom IE toolbar to interact with their portal, and found that when running this on Vista, IE displayed a warning dialog asking the user's consent to run an external program; in particular that was happening when the toolbar was calling a Web Service to retrieve some content from the web server. If for test we denied the permission to run the external problem, we got this error message: "System.Runtime.InteropServices.ExternalException: Cannot execute a program. The command being executed was "C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe" /noconfig /fullpaths @"C:\Users\Vista\AppData\Local\Temp\Low\ev4a0rzg.cmdline"." The exception occurred when the SOAP client proxy tries to spawn the compiler to generate the type serialization assemblies the first time the web service is called.
After the usual log analysis we setup a repro in a virtual machine, and we found that this was not an UAC issue but rather an IE Protected Mode problem (by the way, Protected Mode in IE is currently available only on Vista, so maybe this is why the customer thought to this as an UAC issue); this was confirmed by turning off Protected Mode for a test, and the prompt to the user disappeared. IE was prompting the user because when the toolbar calls the remote Web Service, the CLR needs to generate and compile on the fly the needed serialization assembly, and here is where we were failing. To resolve this we used sgen.exe from the .NET framework SDK: this allows to pre-generate the serialization assemblies, so at runtime the CLR has no need to create them on the fly (and therefore IE does not prompt the user anymore).
After that everything was running file on the virtual machine we used for your tests, but on the real customer's machine we again got an error, this time it was "Could not find a part of the path 'C:\Users\account\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\account\AppData\Local\Temp\Low\6br1dtzk.tmp'"; another dig into the logs, and then we found that the customer was missing a part of the path where IE stores it’s temporary files (%userprofile%\AppData\Local\Temp\Low); for some reason he was missing the “Low” folder and IE was prompting the user to ask permission to create it.
Here are a couple of links to use as a reference:
Carlo
I m working on ie7 toolbar and i also got the error like this "Could not find a part of the path 'C:\Users\account\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\account\AppData\Local\Temp\Low\6br1dtzk.tmp", but cannot find the solution. If some one have a solution, Please help me.
Carlo,
I've run into this problem too and would appreciate a little more info on how you went about using sgen.
Which assembly did you run it against - the one containing the webservice or the one the webservice referenced that contained the actual classes?
Also, once you'd run it, did you have to install the serialisation assemblies in the GAC and do you just deploy them alongside the IE Toolbar assembly?
Thanks!
Andrew
Hi Andrew,
You must sgen the assembly which _calls_ the web service (the IE toolbar assembly, in the example of this post) since this is the one whilch will have to create the serialization proxy at runtime. Then the sgen result *must* be put in the same folder of its originating assembly (again, the IE toolbar assembly) since the runtime will look there by default and I think there is no way to have it look in other folders.
HTH
Thanks for the quick reply Carlo!
Running sgen against the calling assembly (toolbar assembly), adding a ref to the newly created assembly from the toolbar assembly and then deploying the two seems to have no effect.
I should add that the toolbar assembly is signed and registered using regasm (with the /codebase switch). Does one have to sign/regasm the serialisation assembly too?
Is there a way I can check to see if the CLR is at least trying to load the serialisation assembly?
Ok, if you're embedding your assembly in IE check if the serialization one is downloaded too (gacutil /ldl); you can also enable the Fusion log to see if there are any loading failures (in case the runtime for some reason is not able to load the serialization assembly you created), and using Process Monitor you should be able to see if any "compiler" runs on the client (csc.exe, wsdl.exe etc...). If it does, then could mean that the runtime is ignoring your serialization assemblies and creating one on its own (which is not good for our purposes). There should be no need to regasm also the serialization assembly (that allows COM components to see and use your main assembly, but the serialization one is called by your managed component), but to he honest I've never been in this situation so you might want to give it a try anyway (and let me know how it goes).
Carlo, the saga continues :)
With much messing about today, I've managed to get to a point where I can see via Fusion logs that the serialisation assembly is being loaded. However, this only seems to be the case under Windows Server 2003 running IE7. Under Vista it still tries to run csc.exe
Incidently, Fusion doesn't seem to be as reliable at generating logs for IE when running under Vista as it does under Windows Server 2003. Very often when starting IE, and the toolbar loads, there are no logs. Other times, there are - which makes things a little hard to track. Anyway.
The plot thickens when you run IE without protected mode under Vista. In this case, one can see in the fusion logs that the serialisation assembly is being successfully loaded.
In addition, when the serialistion assembly fails to load, the fusion logs also indicate that the Webservice reference isn't being loaded either.
Due to the lack of any precise ordering of the Fusion logs, I can't tell if the Webservice reference is loaded before the serialisation assembly.
Is is possible that protected mode prevents certain things from loading out of the GAC? I hope I'm missing something simple!
Thanks for your help on this, I really appreciate it!
Under Vista did you tried running IE both as Administrator and "normal" user? The difference with Windows 2003 (and XP) is that IE7 on Vista uses different temporary folders ("Low" if you're not running it as Administrator) and this may have an impact; the serialization assembly *must* be in the same folder of it's main assembly because the runtime looks only there, and if it can't be found a new one will be created on the fly as you're describing.
It is certainly possible that protected mode and the new security features under Vista are having an impact, what exactly is hard to tell right now, we need to look at some logs and possibly have a repro to analyze.
Sorry I can't help you more here... but if you want, I suggest you to raise a support call with CSS (Customer Services and Support) and either me or one of my colleagues will look into this issue with you. Have a look at http://support.microsoft.com/gp/services (this is the UK page but you can switch to your local site if you're based in another county) to know which support options you have; you can also mention my name in the problem description, I'll try to take the case myself once created. Let me know if you need assistance in logging the case
Hello there,
Did you find a resolution for this issue? I'm having the exact same problem.
I have managed code running embedded in the Internet Explorer as an "ActiveX" control. It connects to a web service on the backend.
On Vista, with IE7 running protected mode, the CSC compiler runs to compile the web reference.
I've used sgen.exe to create the XmlSerializers.dll, and tried to add it as a reference to the main dll. I've also tried to create a manifest file, and include the XmlSerializers.dll as a dependency within the manifest file.
The CSC compiler still runs despite these steps, so apparently I'm missing something.
The managed code runs without error if I start Internet Explorer as an administrator, or add the web site to the Trusted Site list (protected mode off for trusted sites), or turn Protected Mode off.
Any help would be greatly appreciated. I require the users to install the dll in order to set the .NET Framework permissions, so I could add the site to the trusted site list on the client's machine, and it would work, but this strikes me as a little bit "dirty".
Also, I have to believe that I can run a .NET smart client in a browser without requiring protected mode to be turned off. Hopefully, anyway.
Thanks for any help you could give me.
Mike Vallotton
Mike, what I posted here is the solution to the problem I was working on (I actually wrote this post after the case was closed), so that was enough for the situation we were in...
csc.exe runs every time you call the Web Service or only at startup? Startup may be expected, the CLR still have to JIT compile the application/control; if it runs also when you call the Web Service then for some reason the CLR is not able to find the serialization assembly you created. This assembly *must* be plased in the same folder as the assembly which calls the Web Service since the CLR will look only there.
Have you already tried Process Monitor? Maybe you're missing a folder in the serialization path like in the case I described? Finally the application was running *with* protected mode, so I guess something else is still missing in your case...
As usual, you may consider to open a support call with Microsoft, see my previous comments for details (if you're based in EMEA either me or one of my peers in the InternetDev team will work on it).
Thanks for the quick response, Carlo.
CSC just runs on startup. I'm not sure that the XMLSerializers.dll is even being downloaded from the web site along with the main dll. I need to turn on some logs and see exactly what's going on.
If I can't reach a resolution soon, I'll definitely open a support ticket.
Thanks for the blog - this post especially has been very helpful so far.
Mike
Then you can also use Fiddler (www.fiddler2.com) to trace the HTTP traffic within IE (not on localhost): you'll see all the resources while are downloaded (images, css, .js and other file types). Of course check if you already have the assemblies in the local IE cache, that might prevent the actual download and Fiddler will not trace it
HI there,
I'm facing the exact same problem in my extension. It's a toolbar button developed in C# that consumes a Web Service. It's built on VS2005. I'm getting the "Allow csc.exe" message only at IE7 startup, after allowing it, my extension works ok.
I have a question. I tried what you guys expose here without sucess. My question is, when I build my project in VS2005 it generates a file named "Button.XmlSerializers.dll". What is it? Do I have to register this file via "regasm /codebase" like I do with my button.dll file?
I appreciate any help...
Hello Gonzalo, from the name that seems to be the serialization assembly I was talking about in the post, it *must* be placed in the same folder as your button's assembly (the runtime will look only on that folder to load it and as far as I know this is not configurable).
Did you already give it a try?
Hi Carlo,
I have created the browser extenstion which is connect the database through Webservice. My Toolbar is working fine in XP & Vista, But while trying in IE7 Protected mode ON, i am receiving the same error. For working with Vista, I have created the manifest and embedded into my assembly. Also I have created the XmlSerializers.dll using sgen.exe and included with the primary output in the setup project and make the setup file. And I can find my application installed under C:\Programfiles and inside the application folder, i can found the XmlSerializers.dll with my assmbly. But The Same error appears again while connecting to the webservice.
Could not find a part of the path
'C:\Users\account\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\account\AppData\Local\Temp\Low\6br1dtzk.tmp'";
Please help me to solve this problem.
Parames, the problem you describe seems to be the second one I have in my post, correct? Then the raw and dirty (but working) solution we used with that customer is they check if the "Low" folder (which they were initially missing on the test machine under the virtualized zone) and if it does no they create it before calling the Web Service; at least i their case creating the "Low" folder was enough, the rest of the path is automatically created for you.
Another possible solution you might want to investigate is "Saving Files to the User Profile" at http://msdn.microsoft.com/en-us/library/bb250462.aspx; also the registry keys described in "Starting Processes from Protected Mode" might worth a try.