What is this assembly and why is it there?

Question

I recent noticed, that when I start our rather big application, there are allways two assembly loaded nobody knows what they are. Each time I start debuging the application, the two assemblies are named diffrently.

For example, last time I got this output (it's in German, but you will get it):

...
"start.vshost.exe" (Verwaltet): "C:\Windows\assembly\GAC_MSIL\System.Web.Services\2.0.0.0__b03f5f7f11d50a3a\System.Web.Services.dll" wurde geladen, das Laden von Symbolen wurde übersprungen. Das Modul ist optimiert, und die Debugoption "Nur eigenen Code" ist aktiviert.
"start.vshost.exe" (Verwaltet): "aslf4pbc" wurde geladen
...
"start.vshost.exe" (Verwaltet): "inyuae-m" wurde geladen
"start.vshost.exe" (Verwaltet): "C:\Windows\assembly\GAC_MSIL\Microsoft.JScript\8.0.0.0__b03f5f7f11d50a3a\Microsoft.JScript.dll" wurde geladen, das Laden von Symbolen wurde übersprungen. Das Modul ist optimiert, und die Debugoption "Nur eigenen Code" ist aktiviert.
"start.vshost.exe" (Verwaltet): "C:\Windows\assembly\GAC_MSIL\Microsoft.Vsa\8.0.0.0__b03f5f7f11d50a3a\Microsoft.Vsa.dll" wurde geladen
...

aslf4pbc? inyuae-m?

I had a look at Assembly.CurrentDomain.GetAssemblies() to get some more informations.

Here some informations of the 2 assemblies:

CodeBase / EscapedCodeBase:

"file:///C:/Windows/assembly/GAC_MSIL/system/2.0.0.0__b77a5c561934e089/System.dll"

Location:

""

GlobalAssemblyCache

false

ManifestModule

inyuae-m.dll respectively aslf4pbc.dll

ManifestModule.FullyQualifiedName

"<Unbekannt>" / "<Unknown>"

ManifestModule.Name

"<Unbekannt>" / "<Unknown>"

I couldn't find inyuae-m.dll and aslf4pbc.dll in the filesystem.

There is no info about the location, it seems all quite strange to me. Any ideas? Or am I just missing something?

The application is quite old, it was developed with .Net 2.0, but some newer parts use .Net 3.5 and it consists of circa 25 assemblies.

Answer 1

These are the transient assemblies generated from e.g. in-page code in an ASP.Net application (or indeed anywhere that assemblies are generated on the fly at run time).

Answer 2

These are the names given to transient temporary assemblies created by various api's within the framework to implement runtime code generation.

Xml Serialization does this when they have not been pre-generated for example.

If you really want to know grab the files (which the debugger is attached if you like so as to be able to get to them) and decompile them with reflector.

The internals should give you a good clue as to what triggered their creation.