.NET Framework 3.0 and 3.5 ServiceModelReg.exe custom action failure related to files in the temporary directory
I have run into a few reports of .NET Framework 3.0 and 3.5 installation failures recently that have exhibited the same set of symptoms. I wanted to describe this issue in more detail so that folks who have followed the steps in my previous post about diagnosing .NET Framework 3.0 and 3.5 installation failures related to the ServiceModelReg.exe custom action will recognize this pattern and have some additional workarounds to try to get the .NET Framework to install successfully on their systems.
Diagnosing the issue
When the .NET Framework 3.0 or 3.5 setup fails, I recommend using steps like the ones listed at https://blogs.msdn.com/astebner/archive/2008/03/28/8342307.aspx to narrow down the root cause. Recently, I have heard from a few customers who have used these steps, and when they get to step 4 and look in the event logs on their system, they see errors like the following:
An error occurred while creating the MSI-style log file at 'C:\Documents and Settings\myusername\Local Settings\Temp\':
System.IO.IOException: Unknown error "-1".
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at System.ServiceModel.Install.MsiStyleLogWriter..ctor(String logEntryPrefix).System.IO.IOException: Unknown error "-1".
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
at System.CodeDom.Compiler.TempFileCollection.EnsureTempNameCreated()
at System.CodeDom.Compiler.TempFileCollection.AddExtension(String fileExtension, Boolean keepFile)
at System.CodeDom.Compiler.TempFileCollection.AddExtension(String fileExtension)
at Microsoft.CSharp.CSharpCodeGenerator.FromSourceBatch(CompilerParameters options, String[] sources)
at Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromSourceBatch(CompilerParameters options, String[] sources)
at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource(CompilerParameters options, String[] sources)
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, CompilerParameters parameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, CompilerParameters 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)
at System.Xml.Serialization.XmlSerializer..ctor(Type type)
at System.ServiceModel.Install.Configuration.ConfigurationHandlersInstallComponent..ctor(ConfigurationLoader configLoader)
at System.ServiceModel.Install.Configuration.ConfigurationHandlersInstallComponent.CreateNativeConfigurationHandlersInstallComponent()
at Microsoft.Tools.ServiceModel.ServiceModelReg.BuildActionQueue()
at Microsoft.Tools.ServiceModel.ServiceModelReg.Run(String[] args)
at Microsoft.Tools.ServiceModel.ServiceModelReg.TryRun(String[] args).
Possible root cause of the issue
These call stacks mean that the installation process is running into errors while attempting to create a new file in the temporary directory on the computer. In many of the cases I've seen of this type of error in the past, there was an anti-virus or anti-spyware program running on the system that was preventing applications from creating files in the temporary directory.
Options to work around the issue
When I see this type of error in the event logs during .NET Framework 3.0 or 3.5 installation, I typically suggest trying the following workaround:
- Temporarily disable anti-virus and anti-spyware software on the system
- Try to install the .NET Framework 3.0 or 3.5 again
- Re-enable the anti-virus and anti-spyware software that was disabled in step 1
If those steps are not helpful, then I typically suggest installing the .NET Framework 3.5 SP1 instead of the .NET Framework 3.0 or 3.5.
The reason I suggest this is because the .NET Framework 3.5 SP1 installs the .NET Framework 3.0 SP2 behind the scenes as a prerequisite. The underlying issue described above occurs while running a specific custom action during the .NET Framework 3.0 installation process. In the .NET Framework 3.0 SP2 installer, a logic change was made so that if this particular custom action fails, setup will continue to install instead of failing and rolling back. The end result is that if this action fails in 3.0 SP2, installation will complete and report success, but some specific functionality related to the System.ServiceModel namespace will not work correctly. However, if this scenario arises, it is possible to manually run the ServiceModelReg.exe tool after the fact if this functionality is needed and it isn't working as expected.