locked
pregenerated xmlserializers.dll is not beeing used

    Question

  • hi.

    i have a vs 2010 solution where for one project, the Xmlserializers.dll is produced during the build. However, when the app is run, i still see that the call to XmlSerializer(type) will end up in GenerateTempAssembly() - which afaict means, that instead of using the pregenerated serialization assembly, a _new_ serialization assembly is beeing build. any ideas why this might be the case ?

    WM_THX
    -thomas woelfer


    http://www.die.de/blog
    Wednesday, September 22, 2010 6:22 PM

All replies

  • Please show the code you use to instantiate the XmlSerializer.
    John Saunders
    WCF is Web Services. They are not two separate things.
    Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
    Use File->New Project to create Web Service Projects
    Wednesday, September 22, 2010 7:18 PM
    Moderator
  • John,

    here it is:

    		private static SerializableToolbars LoadInternal( string path)
    {
    var serializer = new XmlSerializertypeofSerializableToolbars));
    TextReader reader = new StreamReader( path);
    var allMenus = (SerializableToolbars)serializer.Deserialize(reader);
    reader.Close();
    return allMenus;    
    }

    http://www.die.de/blog
    Friday, September 24, 2010 12:43 PM
  • Can you turn assembly binding logging to see where it's searching for your assembly?

    http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.100).aspx

     

    Monday, September 27, 2010 10:18 PM
    Moderator
  • Nathan,

    sure. however, the result is "interesting". i have run fuslogvw as admin and started the app as admin. this is the result:

    ------

    *** Assembly Binder Log Entry (28.09.2010 @ 11:21:06) ***
    
    The operation was successful.
    Bind result: hr = 0x0. The operation completed successfully.
    
    Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Running under executable C:\Statik\runtime\Xfalt\Debug\Baustatik.exe
    --- A detailed error log follows. 
    
    === Pre-bind state information ===
    LOG: User = MUENCHEN\twoelfer
    LOG: DisplayName = framework.infrastructure.XmlSerializers, Version=1.0.3919.25894, Culture=neutral, PublicKeyToken=null, processorArchitecture=MSIL
     (Fully-specified)
    LOG: Appbase = file:///C:/Statik/runtime/Xfalt/Debug/
    LOG: Initial PrivatePath = NULL
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = Baustatik.exe
    Calling assembly : System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
    ===
    LOG: This bind starts in default load context.
    LOG: Using application configuration file: C:\Statik\runtime\Xfalt\Debug\Baustatik.exe.Config
    LOG: Using host configuration file: 
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
    LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
    LOG: Attempting download of new URL file:///C:/Statik/runtime/Xfalt/Debug/framework.infrastructure.XmlSerializers.DLL.
    LOG: Assembly download was successful. Attempting setup of file: C:\Statik\runtime\Xfalt\Debug\framework.infrastructure.XmlSerializers.dll
    LOG: Entering run-from-source setup phase.
    LOG: Assembly Name is: framework.infrastructure.XmlSerializers, Version=1.0.3919.25894, Culture=neutral, PublicKeyToken=null
    LOG: Binding succeeds. Returns assembly from C:\Statik\runtime\Xfalt\Debug\framework.infrastructure.XmlSerializers.dll.
    LOG: Assembly is loaded in default load context.
    
    

    it appears the assembly is loaded ok. after running this as admin, i run it as a user w/o admin rights, and then the assembly didn't even show up in fuslogvw. (infact, only very few assemblies where listed.)

    i'm not sure what to make of that: when i run the app under a profiler, i can still see that it's calling GenerateTempAsssembly() in the ctor of the xmlSerializer.

    any ideas?

    WM_THX
    -thomas


    http://www.die.de/blog
    Tuesday, September 28, 2010 9:30 AM
  • A couple of thoughts:

    • run the program in the debugger and look at the load modules after you've created the XmlSerializer, it should only have the .XmlSerializers.dll assembly loaded (not the temp assembly which will have a random name like eqwca20i.dll)
    • to be really sure you can save any generated .cs files with this in your app.config:

    <system.diagnostics>
          <switches>
             <add name="XmlSerialization.Compilation" value="1" />
          </switches>
       </system.diagnostics>

    This will drop any generated cs files in <System Drive>\Users\<Your User Name>\AppData\Local\Temp (you can use process monitor to find out exactly).  Running your program shouldn't generate any new ones.  You can also examine these to see if maybe something else creating an xml serializer.

    Tuesday, September 28, 2010 11:46 PM
    Moderator
  • Nathan,

    i checked in the debugger, and here's what gets loaded during the ctor step:

    'Baustatik.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'
    'Baustatik.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Statik\runtime\Xfalt\Debug\framework.infrastructure.XmlSerializers.dll'
    'Baustatik.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.Services\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.Services.dll'
    'Baustatik.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\tw\AppData\Local\Temp\jodniyba.dll', Symbols loaded.

    the "framework.infrastructure.Xmlserializers.dll" is the one that is beeing created during the build. however, it's also loading a 'jodniyba.dll' one, which is the temp one that gets created.

    i also checked the generated sources, and there i found this:

    --
    public class XmlSerializationWriterSerializableToolbars : System.Xml.Serialization.XmlSerializationWriter {
    --

    (and of course all the rest of it.). so to me this looks like the XmlSerializers dll is not used _or_ the temp dll is beeing generated anyways.

    any further ideas ?

    WM_THX
    -thomas woelfer


    http://www.die.de/blog
    Wednesday, September 29, 2010 4:54 PM
  • If it's possible can you condense this into a small project that reproduces the problem and then file a report here:

    http://connect.microsoft.com/wcf

    The product team will take a look.

    Thanks.

    Friday, October 01, 2010 5:54 PM
    Moderator