locked
Enable32BitAppOnWin64 and Custom Properties RRS feed

  • Question

  • User2134761932 posted
    We're running a Win32 Bit Web Server Application which registeres a couple
    of custom properties in the IIS Meta-Base and uses them during run-time by
    name. When using Windows 2003 64-Bit (US with SP1 and up to date security
    fixes) and the Enable32BitAppOnWin64 functionality this seems to work no
    longer. Actually the Web Server Application would run fine but...

    Long story short: the custom properties are created inside a Win32 ActiveX
    component during installation using the IIS ADSI namespace and the well
    documented schema API. What happens is that the custom properties are all
    registered and working until the IIS restarts! After a restart all
    properties are still there but have lost its names (using the good old
    MetaEdit or directly looking into the MetaBase XML). Since this is so all
    the IIS Meta-Base objects (IIsVirtualDir et al) loose the connections to
    these properties although the values from the time before the restart are
    still set - IIS Meta-Base identifiers are still valid.

    I didn't try if this would work if the installation runs inside a 64-Bit
    context but I would expect this to work. But what I find really strange is
    that the properties are registered first and at least stay in existence (the
    identifiers received from the IIS are not reused) but completly loose names
    after the restart.

    Is this a bug (if so: will it be fixed) or is this by design (if so: why is
    it possible to create these zombies)?

    Thanks for any hint

    Jochen
    Sunday, October 8, 2006 6:52 AM

All replies

  • User10285400 posted

    (Cleaning up old posts) 

    Custom metabase properties was not a well-used part of the product and was a big reason why IIS 7 has a rich configuration extensibility model with administrative tool support.  So we avoid problems like you're seeing.  I'd suggest using some alternative store for your settings such as an .INI file, or the registry (we used these for our URLScan module for it's custom configuration on IIS5 &6). 

    Dave

    Monday, July 13, 2009 1:37 PM