Re: Trusted Assemblies are untrusted after being overwritten

From: Jeff (jeffg_at_goldsystems.com)
Date: 08/04/04 

Date: Wed, 4 Aug 2004 13:00:24 -0700

So what's the correct way to update code in a production
environment? Surely nobody builds something that never
needs updating or changing.

These aren't "regular" changes per se, but this is a
large, ongoing application where features are added now
and then. The client and developers are constantly
thinking of and adding new features to make it a better
application. It's not something that's done hourly,
daily, or even weekly for the most part.

I understand the design and features of the security
module and that it is necessary for all to work well
together.

Maybe my fundamental understanding is flawed for a high
availability front-end web service. I have two or more
IIS servers that need to run this application, and all
need to operate from the same directory structure. That
directory structure, of course, contains the .DLL
assemblies that need to be trusted since they are not on
the local hard disk of any one server.

Ideally it would be nice to say "give full trust to any
assembly on any server as long as it's my domain" or
something similar.

Thanks for your input thus far. I hope you can provide
further insight that clears this up.

Jeff

>-----Original Message-----
>I think you and Microsoft have a fundamental difference
in your way of
>thinking.
>
>As far as MS is concerned, if you're regularly making
changes to the code,
>then it is a development and/or test system, not a "high
availability"
>production system.
>
>As far as your actual problem goes, this happens because
the trusted DLL is
>registered according to its strong name. The strong
name changes every time
>you recompile the code, unless there is absolutely no
difference at all
>between the two assemblies (not even revision number).
>
>..Net assemblies were DESIGNED to be this way,
specifically so that the O/S
>can tell two different dll files apart, even if they
have the same name and
>version info. This is a security feature.
>
>--
>Toby Herring
>MCDBA, MCSD, MCP+SB
>
>
>"Jeff Greenland" <jeffg@goldsystems.com> wrote in message
>news:bb7101c479e6$c5b2e0d0$a601280a@phx.gbl...
>> I've got something that seems to me like there's a
simple
>> solutions I haven't found.
>>
>> First, I have a Windows 2003 Server and IIS6 running
>> a .NET application. I have configured my application
>> files to be located on a network share, rather than the
>> local machine. Security and everything is all set up.
>>
>> In order for the application to work properly, I need a
>> few assemblies to be trusted, which is simple enough.
I
>> just trust the .DLL files using the .NET Configuration
>> Tool.
>>
>> The problem arises when I make a code change in the
>> development environment, then copy the new .DLL to the
>> share location to overwrite the old .DLL that's already
>> trusted. As soon as I do that, the worker processes
>> reset (as they should), but when they start back up,
the
>> updated .DLL is no longer trusted. I have to use
>> the .NET Configuration Tool to re-trust it each time I
>> update the code.
>>
>> Surely there's a simpler solution. Especially since
this
>> is a high availability application where many IIS
servers
>> are accessing the assembly on the share. I can't have
>> my "high availability" services all simultaneously stop
>> functioning because I updated some code.
>>
>> Any suggestions? Thanks in advance,
>>
>> Jeff
>
>
>.
>

Relevant Pages

  • Re: Registration-free activation
    ... with normal COM servers. ... 0x800401f9 "Error in Dll" because the DLL doesn't export DllGetClassObject. ... Phil Wilson ... > The .NET assemblies are shared across several apps, ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Trusted Assemblies are untrusted after being overwritten
    ... the trust level of an assembly using command-line tools? ... ongoing application where features are added now ... >directory structure, of course, contains the .DLL ... >>between the two assemblies. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Radeon is on the "not recommended" list on the SW site
    ... What types of features do you use (solid/surface ... Doing individual parts or assemblies? ... FEA puts a huge load especially on RAM and CPU, ... changed the Radeons to FireGLs and are trying to cover your tracks. ...
    (comp.cad.solidworks)
  • Re: How to share code between two different sites?
    ... application if you have common code for all? ... Three servers are given since all they are for different clients. ... comfortable adding dll to each site manually ) ... You can't add child project to website. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: .NET dll config file
    ... > application has some other .NET dll references. ... assemblies to a separate folder you create problems because you have to tell ... So if your library is called by a "third party application" ... You cannot create a config file just for your DLL. ...
    (microsoft.public.dotnet.framework)