Results 1 to 2 of 2

Thread: Xanderno

  1. #1
    Join Date
    Dec 1969

    Default Xanderno

    A response to your last reply from yesterday:<BR><BR>&#060;i&#062;No, that&#039;s actually not true. Again, it was designed this way on purpose, specifically so that new versions of a dll (or identical versions with different innards, from different vendors *wouldn&#039;t* overwrite each other, and muck up the works for existing applications. ... Not at all! This is *exactly* what the new model is in place to prevent. Yes, it would make your particular situation easier, but this behaviour is what caused all manner of problems in the COM days.&#060;/i&#062;<BR><BR>You see, in my current position (which I am sure is a very common one), the exact opposite is true. I work for a company at the enterprise level and we are writing libraries that must be used by all applications, mainly for security and a set of developer tools, etc. I would have to assume that this is extremely standard in any medium to large firm.<BR><BR>In the long run, we may end up having hundreds and hundreds of places where .NET applications reside. Multiple web servers, desktop software applications, etc.<BR><BR>The goal is to create a library DLL that is shared on a given machine by all .NET apps that use it. Now, using the GAC, this is taken care of. The real problem comes into play when you want to update your library dll. Let&#039;s say you find a gaping security hole and you fix it within your library source code, recompile, etc.<BR><BR>Once this library is updated, it is assumed that it MUST be updated for all other applications in the firm (as long as we&#039;re changing its functionality entirely). To assume that a complex security/permissions related library will be right from day 1 and never need to be fixed is a poor assumption.<BR><BR>Because the GAC requires the strongly named item, you can&#039;t just replace the DLL. You have to replace, and ALSO recompile every single .NET application that references it. That borders on insanity when you consider the number of applications (and testing that would need to be done).<BR><BR>The other option, which is easier to do, is to forego the GAC entirely and just drop your library DLL in every single application&#039;s BIN folder. This would seem like a unideal solution as well, especially when you would have to maintain hundreds of different locations almost simultaneously. This is the option we are currently going with. We&#039;re going to have to create an entire application to track and update Security.dll in all of its locations. This shouldn&#039;t be required.<BR><BR>I understand why Microsoft modified their DLL practices, and they are nice and powerful, but there should be some option within your assemblies where you can say:<BR><BR>1. I want to use a shared DLL (machine-wide)<BR>2. I want the ability to replace it without requiring a recompile<BR>3. It would be nice if I could increment a version number too (to make life easier when looking at what versions reside where)<BR><BR>In my opinion, since 99% of the work I have done for the past 5 years is along these lines, this is not too much to ask for. In fact, I keep assuming there is some way to do it and I just keep failing to see it.<BR><BR>In my environment, we&#039;re really not concerned about &#060;i&#062;someone&#060;/i&#062; replacing a DLL with an older version, because for this type of DLL there should never be an older version in use. We&#039;re also not worried about 3rd party DLLs causing problems because we control everything from the ground up.<BR><BR>I hope this all makes sense.

  2. #2
    Join Date
    Dec 1969

    Default RE: Xanderno

    It does make sense, and I *do* agree that it would make your situation easier to deal with. <BR><BR>I don&#039;t necessarily agree, however, that it&#039;s the *best* solution. <BR><BR>This really is, in my experience, a relatively uncommon senario. I do deal with a number of large enterprise clients, both corporate, and governmental agencies, and this is not a situation that I&#039;ve run into. <BR><BR>The really issue is abuse. Certainly you can control your environment, but in many situations, people are using vendor provided apps that they don&#039;t have the same level of control over. They don&#039;t want those vendors to have the option to overwrite each other&#039;s dlls willy-nilly. <BR><BR>The way that .Net handles assemblies right now is the result of customer requests....When they announces at the .Net launch event that there would be strong versioning on assemblies, the audience erupted with applause. Overall, it&#039;s really for the best. <BR><BR>In an enterprise environment, you&#039;re always going to have deployment issues. Look at OS patches, and service packs, for instance. It&#039;s not fun running around the office at 1 in the morning manually pushing service packs to hundreds of workstations...And I know, &#039;cause I had to do it back in the NT4 days before we had an SMS server to handle that for us. That&#039;s why SMS exists, in fact, so that admins could automate deployments and control software configurations. Automated build tools, and scripts for deployment aren&#039;t a big deal to use, and they&#039;re designed to handle these kinds of enterprise issues. It&#039;s more work initially, but they can greatly reduce the amount of effort that it takes you in the long run. <BR><BR><BR>I simply don&#039;t think that the issues that would be caused by weaking the .Net versioning system would be worth the benefits. <BR><BR>Cheers,<BR><BR>Xander

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts