The infamous Could Not Find File c:\Windows\Temp\xxxxx.dll error in .net

Hey. I was just wondering if any folks on these forums have ever run into the following error right at the shipping computation or payment sections of checkout on NopC 1.4

http://stackoverflow.com/questions/883551/xmlserializer-could-not-find-file-c-windows-temp-dll

This points to a potential fix as such...

http://stackoverflow.com/questions/134224/generating-an-xml-serialization-assembly-as-part-of-my-build

Anyone run into this situation before with NopC?

I have a client that can go for days or hours without recieving that "Could not find file c:\\Windows\Temp\xxxxxx.dll" error but then it goes ape crazy and gets it very often ; only in the portions of nopC that do https xml serialization it seem. (basically, any part it communicates to a web service during, ups, google paypal). Unfortunately, that's the most important part of the checkout process usually.

Any help would be greatly appreciated.

Hi
It happened to me when dealing with google checkout in Medium Trust hosting. First of all when I wanted to set google checkout in the admin panel, it wants to change web.config - it fails with this error.

Another case I can think about it's when XmlSerializer serializes some dll that requires full trust, but the serialization is being run under medium trust hosting.

Does anyone know if xmlserialization had been introduced in nopC 1.4 by any chance? My customer swears they were never getting this \Windows\Temp\xxxxxxxx.dll error when they had a working copy of nopC 1.2 on the production site.

Just placing an MSDN article on similar topic here. For folks to additionally review (and posterity sake for others potentially having this problem.)

From what I can tell from a lot of additional research and testing, by default, most Visual Studio Web Application solutions have all of their code libraries and web site folders set with "Auto" xml serialization set in their Project attributes / Build tab. What this means, from what I can tell, is that when properly compiled as a "Release" version of the NopC application, then it at least appears like any new types that are xmlserialized within the project (I assume based upon Build Order as not all payment and shipping dll appear to have mydllname.xmlserializers.dll built for them).

The problem I see overall with how the NopC download "no source" edition was composed, is that it includes a "Debug" version of NopC, and not a "Release" version. Also an issue is seen in the subsequent Web.Config, in the "no source" release, which includes compilation debug = "true" which in every online reference I've found is not good to use on a production site. This leads me to believe that the 100s of canned installed NopC sites out there in internet-land have been installed in Debug mode. That's not very good on ISP server loads , nor in the situation mentioned in this particular thread. As xmlserialization takes extra time to compile every time a person checks out in NopC or has shipping determined via web services to UPS or other behind-the-scenes SOAP methods within NopC.

Long story short, does this mean everyone should run out and change their installation settings? No. If you are running fine, so be it. But I'm hoping the NopC dev team will read this, and consider in the "no source" editions, to make sure that it is optimized if possible in future editions.

To the thread at hand, I have recompiled my customer's 1.4 customized site as "Release" build, and hence, several xmlserializers.dll files were created in the /bin/ folder. I'm hoping this will get around the occasional "Could not find file c:\\Windows\Temp\xxxxxxxx.dll" issue, as this is utilized within NopC during the creation of new types using the object xmlserializer within the code.

I will report further if this finally fixes my customer's issues or not. Then I will write-up something a little more solid and place online somewhere for other developer's usage.

Thanks for your virtual ears...