¿Acceso denegado al eliminar el ensamblaje creado por una compilación de codidomprovider?

Question

Si usa la clase CODEDOMPROVIDER en .NET después de que se complete la compilación, no puede eliminar el ensamblaje de salida.Quiero poder eliminar el conjunto de salida.File.delete devuelve una excepción de acceso denegado.

string asmPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString("N") + ".exe");
string keyPath = "some path to a *.snk file that works";
// build compiler
CodeDomProvider dom = CodeDomProvider.CreateProvider("VisualBasic");
CompilerParameters cp = new CompilerParameters();
cp.TreatWarningsAsErrors = false;
cp.GenerateInMemory = false;
cp.GenerateExecutable = true;
cp.CompilerOptions = "/target:winexe /keyfile:\"" + keyPath + "\"";
cp.OutputAssembly = asmPath;
// add all the other assembly references
string netPath = @"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\";
cp.ReferencedAssemblies.Add(netPath + @"System.dll");
cp.ReferencedAssemblies.Add(netPath + @"System.Core.dll");
cp.ReferencedAssemblies.Add(netPath + @"System.Data.dll");
cp.ReferencedAssemblies.Add(netPath + @"System.Xml.dll");
CompilerResults cr = dom.CompileAssemblyFromSource(cp, new string[] { code });
if (cr.Errors.Count == 0)
{
    cr.TempFiles.Delete();
    dom.Dispose();
// do stuff
...
//
    File.Delete(asmPath); // fails here Access Denied
}

Editar Como trabajo que estoy usando un constructor estático en la clase que busca la carpeta TEMP y elimina las asambleas creadas anteriormente.

Answer 1

I suspect the problem is that the assembly is loaded (in memory), and has the output file open, just as any other assembly that is currently loaded will have a handle to its executable file.

It's also possible (although I consider it unlikely) that the dom instance or the CompilerResults instance has a reference to the opened file. Neither is IDisposable, so I suspect they're not holding the file open.

Possible solutions:

You can compile the assembly to memory. That is, don't output a file. That solves the immediate problem. However, you still have the problem that the compiled assembly remains in memory. There's no way to unload an assembly without tearing down the app domain.

You can create a separate app domain to do the compile, and then communicate the results back to your main app domain. You can then shut down the compiler app domain, which will remove the compiled assembly from memory and also release any file handles that are referencing the file you just created. Your main program can then delete the file in question.