Microsoft free e-books

Subject is located by the link

Posted in .NET | Leave a comment

How to discover a named pipe which WCF service uses?

If you ever needed to discover a named pipe which was in use by WCF to troubleshoot some issues, you should face that this was not possible to do in some straight open way. But there is a cool guy who did that already. Here, links to his posts on the topic:

– Issue description

– Console util

Posted in .NET, Hack, WCF | Leave a comment

ClickOnce and Google Chrome

ClickOnce and Google Chrome don’t pal up each other. If ClickOnce application is configured to be installed from a server and when you click on its link in Google Chrome then the browser will download the file and you will try to install the app from your local path. But a reference to its manifest file will be relative to this local path when the manifest itself will be located at the server. Of course, IE services the *.application links correctly. And yeah, the related error would be in the details like this:

Downloading file:///*.exe.manifest did not succeed


P.S.: To fix that for Chrome one could download from Google Webstore an extension called “ClickOnce for Google Chrome™” which handles those links as desired.

Posted in ClickOnce | Leave a comment

There was an error attaching the debugger to the IIS worker process

When I was trying to run the asp .net application via Azure Emulator, Visual Studio showed me such an error “There was an error attaching the debugger to the IIS worker process bla-bla-bla”. There are a lot of causes for the situation. I would recommend  the best way to troubleshoot this error is to try deploy the site to IIS manually and see if it runs. So I did that and it was not running. The 500 http error said me that an handler was incorrectly registered within IIS. So I went to “Turn Windows Features On\Off” and switched ASP .NET feature beside with authentication options. Restart and voila – everything worked!

Posted in .NET, ASP .NET, ASP .NET MVC, Windows Azure | Leave a comment

Default XmlSerializer uses %TMP% folder to generate an assembly dynamically.

I got such a stack trace today:

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\Windows\TEMP\elfzvfzu.0.cs' could not be found
error CS2008: No inputs specified

at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)

And it was a surprise for me that System.Xml.Serialization.XmlSerializer creates an assembly dynamically under the covers and it uses %TMP% folder for this purposes.  Be aware of that because you may not have access to the folder within some environments and identities.

Posted in .NET | 1 Comment