|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
How can I use a dll with several programs?Hello,
I have this problem: I wrote some DLLs with VB.Net 2003 which I use with my programs. But I want to avoid that I have to go down to "DLL hell" and to copy all used dlls into each program directory. Does anyone have an idea how I can avoid that? Thanks in advance! Best Regards, HKSHK Prepare your assembly with a strong name and register it into the Global
Assembly Cache (GAC). Then you can have several applications use it but only maintain one copy that is in a central location. Show quoteHide quote "HKSHK" <hk***@gmx.net> wrote in message news:44f050c8$0$24209$9b622d9e@news.freenet.de... > Hello, > > I have this problem: > I wrote some DLLs with VB.Net 2003 which I use with my programs. But I > want to avoid that I have to go down to "DLL hell" and to copy all used > dlls into each program directory. > > Does anyone have an idea how I can avoid that? > > Thanks in advance! > > Best Regards, > > HKSHK Pleas investigate the true meanings of the term Dll hell , people who
programmed and deployed Vb6 , Delphi etc etc applications on win32 will know what i mean :-) ..Net is the solution for the Dll hell In the past when programmers dumped there dll`s in system32 we had lots of problems with versioning of dll`s ( we needed to write intelligent setup`s and even then it sometimes broke another or your own app ) With .Net we can just put the required dll`s in the assembly directory ( or if you prefer and add a config entry in a sub directory below the assembly dir ) however we talk about Xcopy deployment if you call that Dll hell well then praise the lord you started ( probably ) with .Net http://en.wikipedia.org/wiki/DLL_hell The solution for your problem ?? ,,, is in my opinion to create a setup project for your proggy In my opinion the GAC is only to be used with BL objects in corporate environments , in all other situations it is a ticking time bomb ( stay away of it as it were the plague ) regards Michel Posseth [MCP] Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:eE21jiRyGHA.3440@TK2MSFTNGP06.phx.gbl... > Prepare your assembly with a strong name and register it into the Global > Assembly Cache (GAC). Then you can have several applications use it but > only maintain one copy that is in a central location. > > > "HKSHK" <hk***@gmx.net> wrote in message > news:44f050c8$0$24209$9b622d9e@news.freenet.de... >> Hello, >> >> I have this problem: >> I wrote some DLLs with VB.Net 2003 which I use with my programs. But I >> want to avoid that I have to go down to "DLL hell" and to copy all used >> dlls into each program directory. >> >> Does anyone have an idea how I can avoid that? >> >> Thanks in advance! >> >> Best Regards, >> >> HKSHK > > > In my opinion the GAC is only to be used with BL objects in corporate LOL - I think you just need to do some investigating about the GAC. It's > environments , in all other situations it is a ticking time bomb ( stay > away of it as it were the plague ) not the best solution all the time, but in many situations (like commonly used assemblies), it may be just the ticket to simpler deployment and version control. > LOL - I think you just need to do some investigating about the GAC. It's The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast. > not the best solution all the time, but in many situations (like commonly > used assemblies), it may be just the ticket to simpler deployment and > version control. For all intents and purposes, it provides what COM and windows\system32 do, i.e. a machine-wide place to drop shared DLLs. Of course, the problems with sharing DLLs in a machine-wide spot is that it leads to a set of well-known problems collectively called "DLL Hell." There are many problems, but the biggest is that when a shared DLL is updated, you're really updating an unknown set of applications. If the set of applications is unknown, how can you possible test them before making this change? And if you can't test them, you're likely to break them. What this boils down to is that any of the shared spots for updates, whether it's a COM CLSID, windows\system32 or the GAC, are dangerous and should be avoided. And this is why the preferred ..NET deployment scenario is "xcopy deployment," i.e. having your own private copy of each DLL that you test and deploy with the rest of your application. Aha!" you say. "The GAC supports multiple version of an assembly! When a foo.dll is updated to v1.1, v1.0 sits right along side of it so that your app *doesn't* break!" Of course, that's absolutely true. But if that's the case, why do you care? I mean, if there's a new assembly available but your app isn't picking it up, what difference does it make? "Aha again!, you say. "I can put a publisher policy into the GAC along with my assembly so that apps *are* updated automatically!" That's true, too, but now, like any of the machine-wide code replacement strategies of old, you're on the hook for an awesome responsibility: making sure that as close to 0% of apps, known to you or not, don't break. This is an awesome responsibility and one that takes MS hundreds of man-years at each new release of the .NET Framework So using the GAC is bringing back the Dll hell that is my statement ( also in my previous post ) i do not see anything funny about it i am bloody serious about it as i said there are situations were the GAC might be a good solution , however in these scenario`s you have a big responsability that is why i said use it only in a managed environment ( that`s just my opinion ) . regards Michel Posseth [MCP] Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:eAy2eFTyGHA.3568@TK2MSFTNGP03.phx.gbl... >> In my opinion the GAC is only to be used with BL objects in corporate >> environments , in all other situations it is a ticking time bomb ( stay >> away of it as it were the plague ) > > > LOL - I think you just need to do some investigating about the GAC. It's > not the best solution all the time, but in many situations (like commonly > used assemblies), it may be just the ticket to simpler deployment and > version control. > Thanks for that unsolicited dissertation. It seems that your biggest beef
with the GAC is the possibility of a new version of a .dll unintentionally breaking the applications that are using it. This really boils down to a single point. Maintaining backwards compatibility of a .dll by keeping its interface the same during updates. This has absolutely ZERO to do with the GAC and everything to do with competence in OOP by the programmer. The introduction of the GAC is what largely removed DLL Hell from the Windows programming radar. DLL Hell was 50% based on incorrect registry entries and since .NET assemblies don't utilize the Windows registry, we can eliminate those problems. The other 50% of DLL Hell problems came from versioning. But since the GAC was designed to allow for multiple version registration (strong naming being the key to unique identification not the actual .dll name), multiple versions and policies make this a snap as well. Your statement was: >>> In my opinion the GAC is only to be used with BL objects in corporate Which is ridiculous! It is neither informative nor does it show any real >>> environments , in all other situations it is a ticking time bomb ( stay >>> away of it as it were the plague ) understanding of what the GAC is and when and why it is VERY useful. Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> wrote in message news:ubwOSEcyGHA.5048@TK2MSFTNGP05.phx.gbl... >> LOL - I think you just need to do some investigating about the GAC. It's >> not the best solution all the time, but in many situations (like commonly >> used assemblies), it may be just the ticket to simpler deployment and >> version control. > > > The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast. > For all intents and purposes, it provides what COM and windows\system32 > do, i.e. a machine-wide place to drop shared DLLs. Of course, the problems > with sharing DLLs in a machine-wide spot is that it leads to a set of > well-known problems collectively called "DLL Hell." There are many > problems, but the biggest is that when a shared DLL is updated, you're > really updating an unknown set of applications. If the set of applications > is unknown, how can you possible test them before making this change? And > if you can't test them, you're likely to break them. What this boils down > to is that any of the shared spots for updates, whether it's a COM CLSID, > windows\system32 or the GAC, are dangerous and should be avoided. And this > is why the preferred .NET deployment scenario is "xcopy deployment," i.e. > having your own private copy of each DLL that you test and deploy with the > rest of your application. > > Aha!" you say. "The GAC supports multiple version of an assembly! When a > foo.dll is updated to v1.1, v1.0 sits right along side of it so that your > app *doesn't* break!" Of course, that's absolutely true. But if that's the > case, why do you care? I mean, if there's a new assembly available but > your app isn't picking it up, what difference does it make? > "Aha again!, you say. "I can put a publisher policy into the GAC along > with my assembly so that apps *are* updated automatically!" That's true, > too, but now, like any of the machine-wide code replacement strategies of > old, you're on the hook for an awesome responsibility: making sure that as > close to 0% of apps, known to you or not, don't break. This is an awesome > responsibility and one that takes MS hundreds of man-years at each new > release of the .NET Framework > > > So using the GAC is bringing back the Dll hell that is my statement ( also > in my previous post ) i do not see anything funny about it i am bloody > serious about it > as i said there are situations were the GAC might be a good solution , > however in these scenario`s you have a big responsability that is why i > said use it only in a managed environment ( that`s just my opinion ) . > > > regards > > Michel Posseth [MCP] > > > "Scott M." <s-mar@nospam.nospam> schreef in bericht > news:eAy2eFTyGHA.3568@TK2MSFTNGP03.phx.gbl... >>> In my opinion the GAC is only to be used with BL objects in corporate >>> environments , in all other situations it is a ticking time bomb ( stay >>> away of it as it were the plague ) >> >> >> LOL - I think you just need to do some investigating about the GAC. It's >> not the best solution all the time, but in many situations (like commonly >> used assemblies), it may be just the ticket to simpler deployment and >> version control. >> > > Scott,
I found it a nice discussion, why bring it in this way, as "unsolicited dissertation" . All what we, in my opinion including you, write or do in this newsgroup is unsolicited. It is a gift to others trying to deal them in our knowledge hoping the other will do the same to bring ourselves to the best conclusions. Just my thought reading your message. Cor Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:utIhi3eyGHA.1292@TK2MSFTNGP03.phx.gbl... > Thanks for that unsolicited dissertation. It seems that your biggest beef > with the GAC is the possibility of a new version of a .dll unintentionally > breaking the applications that are using it. This really boils down to a > single point. Maintaining backwards compatibility of a .dll by keeping > its I used those terms because Michel was trying to back up a ridiculous
statement with what seemed to me as a dissertaion that was not requested, needed or even accurate. He followed one bogus statement with another. Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:e$uOuGfyGHA.4176@TK2MSFTNGP06.phx.gbl... > Scott, > > I found it a nice discussion, why bring it in this way, as "unsolicited > dissertation" . > > All what we, in my opinion including you, write or do in this newsgroup > is unsolicited. It is a gift to others trying to deal them in our > knowledge hoping the other will do the same to bring ourselves to the best > conclusions. > > Just my thought reading your message. > > Cor > > "Scott M." <s-mar@nospam.nospam> schreef in bericht > news:utIhi3eyGHA.1292@TK2MSFTNGP03.phx.gbl... >> Thanks for that unsolicited dissertation. It seems that your biggest >> beef with the GAC is the possibility of a new version of a .dll >> unintentionally breaking the applications that are using it. This really >> boils down to a single point. Maintaining backwards compatibility of a >> .dll by keeping its > > >>> Thanks for that unsolicited dissertation Well if i translate this to my native tongue ( ongevraagde verhandeling ) it is a bit offensive to me Sorry but if this is the way you discuss with people i stop responding right away , maybe i misunderstood the word discussion group wrong when i started participating . However it is clear to me that you are a Russian democrat , however a lot of people think different and this has nothing to do with not understanding but other points of view . And in this case i have another point of view wich is perfectly valid but aparently not for you , you do not even hear my arguments in the discussion it is good for a person to talk but i respect a person more as he also can listen . So i will now move on maybe i can make someone else happy with my "unsolicited dissertation`s" ,,, Kind regards, Michel Posseth [MCP] Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:utIhi3eyGHA.1292@TK2MSFTNGP03.phx.gbl... > Thanks for that unsolicited dissertation. It seems that your biggest beef > with the GAC is the possibility of a new version of a .dll unintentionally > breaking the applications that are using it. This really boils down to a > single point. Maintaining backwards compatibility of a .dll by keeping > its interface the same during updates. > > This has absolutely ZERO to do with the GAC and everything to do with > competence in OOP by the programmer. The introduction of the GAC is what > largely removed DLL Hell from the Windows programming radar. DLL Hell was > 50% based on incorrect registry entries and since .NET assemblies don't > utilize the Windows registry, we can eliminate those problems. The other > 50% of DLL Hell problems came from versioning. But since the GAC was > designed to allow for multiple version registration (strong naming being > the key to unique identification not the actual .dll name), multiple > versions and policies make this a snap as well. > > Your statement was: > >>>> In my opinion the GAC is only to be used with BL objects in corporate >>>> environments , in all other situations it is a ticking time bomb ( >>>> stay away of it as it were the plague ) > > Which is ridiculous! It is neither informative nor does it show any real > understanding of what the GAC is and when and why it is VERY useful. > > > "Michel Posseth [MCP]" <M***@posseth.com> wrote in message > news:ubwOSEcyGHA.5048@TK2MSFTNGP05.phx.gbl... >>> LOL - I think you just need to do some investigating about the GAC. >>> It's not the best solution all the time, but in many situations (like >>> commonly used assemblies), it may be just the ticket to simpler >>> deployment and version control. >> >> >> The .NET Global Assembly Cache (GAC) is a misunderstood and misused >> beast. For all intents and purposes, it provides what COM and >> windows\system32 do, i.e. a machine-wide place to drop shared DLLs. Of >> course, the problems with sharing DLLs in a machine-wide spot is that it >> leads to a set of well-known problems collectively called "DLL Hell." >> There are many problems, but the biggest is that when a shared DLL is >> updated, you're really updating an unknown set of applications. If the >> set of applications is unknown, how can you possible test them before >> making this change? And if you can't test them, you're likely to break >> them. What this boils down to is that any of the shared spots for >> updates, whether it's a COM CLSID, windows\system32 or the GAC, are >> dangerous and should be avoided. And this is why the preferred .NET >> deployment scenario is "xcopy deployment," i.e. having your own private >> copy of each DLL that you test and deploy with the rest of your >> application. >> >> Aha!" you say. "The GAC supports multiple version of an assembly! When a >> foo.dll is updated to v1.1, v1.0 sits right along side of it so that your >> app *doesn't* break!" Of course, that's absolutely true. But if that's >> the case, why do you care? I mean, if there's a new assembly available >> but your app isn't picking it up, what difference does it make? >> "Aha again!, you say. "I can put a publisher policy into the GAC along >> with my assembly so that apps *are* updated automatically!" That's true, >> too, but now, like any of the machine-wide code replacement strategies of >> old, you're on the hook for an awesome responsibility: making sure that >> as close to 0% of apps, known to you or not, don't break. This is an >> awesome responsibility and one that takes MS hundreds of man-years at >> each new release of the .NET Framework >> >> >> So using the GAC is bringing back the Dll hell that is my statement ( >> also in my previous post ) i do not see anything funny about it i am >> bloody serious about it >> as i said there are situations were the GAC might be a good solution , >> however in these scenario`s you have a big responsability that is why i >> said use it only in a managed environment ( that`s just my opinion ) . >> >> >> regards >> >> Michel Posseth [MCP] >> >> >> "Scott M." <s-mar@nospam.nospam> schreef in bericht >> news:eAy2eFTyGHA.3568@TK2MSFTNGP03.phx.gbl... >>>> In my opinion the GAC is only to be used with BL objects in corporate >>>> environments , in all other situations it is a ticking time bomb ( >>>> stay away of it as it were the plague ) >>> >>> >>> LOL - I think you just need to do some investigating about the GAC. >>> It's not the best solution all the time, but in many situations (like >>> commonly used assemblies), it may be just the ticket to simpler >>> deployment and version control. >>> >> >> > > I also think you have also been looking at this from only 1 side of the
fence. Using the GAC has many other benefits (security and performance) that you do not get with private assemblies. To simply say "don't use the GAC" because someone else may write bad code is, IMHO, absurd. Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> wrote in message news:ubwOSEcyGHA.5048@TK2MSFTNGP05.phx.gbl... >> LOL - I think you just need to do some investigating about the GAC. It's >> not the best solution all the time, but in many situations (like commonly >> used assemblies), it may be just the ticket to simpler deployment and >> version control. > > > The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast. > For all intents and purposes, it provides what COM and windows\system32 > do, i.e. a machine-wide place to drop shared DLLs. Of course, the problems > with sharing DLLs in a machine-wide spot is that it leads to a set of > well-known problems collectively called "DLL Hell." There are many > problems, but the biggest is that when a shared DLL is updated, you're > really updating an unknown set of applications. If the set of applications > is unknown, how can you possible test them before making this change? And > if you can't test them, you're likely to break them. What this boils down > to is that any of the shared spots for updates, whether it's a COM CLSID, > windows\system32 or the GAC, are dangerous and should be avoided. And this > is why the preferred .NET deployment scenario is "xcopy deployment," i.e. > having your own private copy of each DLL that you test and deploy with the > rest of your application. > > Aha!" you say. "The GAC supports multiple version of an assembly! When a > foo.dll is updated to v1.1, v1.0 sits right along side of it so that your > app *doesn't* break!" Of course, that's absolutely true. But if that's the > case, why do you care? I mean, if there's a new assembly available but > your app isn't picking it up, what difference does it make? > "Aha again!, you say. "I can put a publisher policy into the GAC along > with my assembly so that apps *are* updated automatically!" That's true, > too, but now, like any of the machine-wide code replacement strategies of > old, you're on the hook for an awesome responsibility: making sure that as > close to 0% of apps, known to you or not, don't break. This is an awesome > responsibility and one that takes MS hundreds of man-years at each new > release of the .NET Framework > > > So using the GAC is bringing back the Dll hell that is my statement ( also > in my previous post ) i do not see anything funny about it i am bloody > serious about it > as i said there are situations were the GAC might be a good solution , > however in these scenario`s you have a big responsability that is why i > said use it only in a managed environment ( that`s just my opinion ) . > > > regards > > Michel Posseth [MCP] > > > "Scott M." <s-mar@nospam.nospam> schreef in bericht > news:eAy2eFTyGHA.3568@TK2MSFTNGP03.phx.gbl... >>> In my opinion the GAC is only to be used with BL objects in corporate >>> environments , in all other situations it is a ticking time bomb ( stay >>> away of it as it were the plague ) >> >> >> LOL - I think you just need to do some investigating about the GAC. It's >> not the best solution all the time, but in many situations (like commonly >> used assemblies), it may be just the ticket to simpler deployment and >> version control. >> > > Scott
Using the GAC has it`s advantages however my statement is that i would not trade these advantages for the dissadvanages that i get in return My main problem with the GAC is that it increases the complexity of installing and uninstalling your application <snip from answer to Herfried > My aversion against the GAC is due to the fact that you are depending in the end on a reference count for every version to make sure that it is there and won`t break apps, my personal opinion is that it introduces unnecesay deployment complexity ( write an installer that delivers a file to the GAC to call one, need of administrator interference due to system ACL ) Most people use Gacutil.exe or Xcopy to deploy there assembly to the GAC while they should use a installer to do so because these do not provide assembly reference counting . </snip from answer to Herfried > About the security and perfomance perfomance : Wich perfomance you mean the nanosecond it takes to locate the assembly ?? ( i know GAC is the first place it looks however second is the app dir ) for the rest i can`t find anny perfomance benefit in the documentation i have ( an i do own a impressive library ) security : That is just how you look at it , Installers are designed to work in a non administrative modus , however when i do a installation to the GAC i must be an administrator due to the fact of system ACL ( you do not want to grant write permissions for your users on the system directory`s ) so in the end it costs more complexity again to even deploy your app or it costs essential security . again : every advantage has a dissadvantage it is just what is more worth to you ( it is obvious that i choose a different path as you ) PS. For me this was a apreciated discussion , until you decided to imitate a one party democratic structure :-) i was and am just telling my arguments why i would not use the GAC in my situation ( deployable app ) if you would ask me the same thing in a managed corporate environment well in this situation i have another opinion ( although i recently started working in such an environment and i use a global application directory , as this is easier with Kix scripting for our system administrator ) regards Michel Posseth [MCP] Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:e01eF9eyGHA.4976@TK2MSFTNGP04.phx.gbl... >I also think you have also been looking at this from only 1 side of the >fence. Using the GAC has many other benefits (security and performance) >that you do not get with private assemblies. To simply say "don't use the >GAC" because someone else may write bad code is, IMHO, absurd. > > > "Michel Posseth [MCP]" <M***@posseth.com> wrote in message > news:ubwOSEcyGHA.5048@TK2MSFTNGP05.phx.gbl... >>> LOL - I think you just need to do some investigating about the GAC. >>> It's not the best solution all the time, but in many situations (like >>> commonly used assemblies), it may be just the ticket to simpler >>> deployment and version control. >> >> >> The .NET Global Assembly Cache (GAC) is a misunderstood and misused >> beast. For all intents and purposes, it provides what COM and >> windows\system32 do, i.e. a machine-wide place to drop shared DLLs. Of >> course, the problems with sharing DLLs in a machine-wide spot is that it >> leads to a set of well-known problems collectively called "DLL Hell." >> There are many problems, but the biggest is that when a shared DLL is >> updated, you're really updating an unknown set of applications. If the >> set of applications is unknown, how can you possible test them before >> making this change? And if you can't test them, you're likely to break >> them. What this boils down to is that any of the shared spots for >> updates, whether it's a COM CLSID, windows\system32 or the GAC, are >> dangerous and should be avoided. And this is why the preferred .NET >> deployment scenario is "xcopy deployment," i.e. having your own private >> copy of each DLL that you test and deploy with the rest of your >> application. >> >> Aha!" you say. "The GAC supports multiple version of an assembly! When a >> foo.dll is updated to v1.1, v1.0 sits right along side of it so that your >> app *doesn't* break!" Of course, that's absolutely true. But if that's >> the case, why do you care? I mean, if there's a new assembly available >> but your app isn't picking it up, what difference does it make? >> "Aha again!, you say. "I can put a publisher policy into the GAC along >> with my assembly so that apps *are* updated automatically!" That's true, >> too, but now, like any of the machine-wide code replacement strategies of >> old, you're on the hook for an awesome responsibility: making sure that >> as close to 0% of apps, known to you or not, don't break. This is an >> awesome responsibility and one that takes MS hundreds of man-years at >> each new release of the .NET Framework >> >> >> So using the GAC is bringing back the Dll hell that is my statement ( >> also in my previous post ) i do not see anything funny about it i am >> bloody serious about it >> as i said there are situations were the GAC might be a good solution , >> however in these scenario`s you have a big responsability that is why i >> said use it only in a managed environment ( that`s just my opinion ) . >> >> >> regards >> >> Michel Posseth [MCP] >> >> >> "Scott M." <s-mar@nospam.nospam> schreef in bericht >> news:eAy2eFTyGHA.3568@TK2MSFTNGP03.phx.gbl... >>>> In my opinion the GAC is only to be used with BL objects in corporate >>>> environments , in all other situations it is a ticking time bomb ( >>>> stay away of it as it were the plague ) >>> >>> >>> LOL - I think you just need to do some investigating about the GAC. >>> It's not the best solution all the time, but in many situations (like >>> commonly used assemblies), it may be just the ticket to simpler >>> deployment and version control. >>> >> >> > > Michel,
>again : every advantage has a dissadvantage I thought Scott is an American, do you think he knows Johan CruyffCor I just knew you would react on this :-)
But i just hope he gets the point Groeten Michel Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schreef in bericht news:OTkL$2fyGHA.2036@TK2MSFTNGP05.phx.gbl... > Michel, > >>again : every advantage has a dissadvantage > > I thought Scott is an American, do you think he knows Johan Cruyff > > Cor > > It is a discussion Michel. And so, I have the right to respond as I see fit
(are you disagreeing with that?). If you took personal offense at my remark, I apologize, perhaps the American term "rant" would have been more appropriate. You originally wrote: "in all other situations it is a ticking time bomb ( stay away of it as it were the plague )". Which is an absurd statement, based on no fact whatsoever. Since then, you have loosened your original stance a bit, but you still haven't written anything that indicates to me that you truly (and more importantly) understand the function of the GAC. One example would be that on performance, you simply talk about the "nanosecond" quicker an application may start. Well, I haven't measured myself, but I believe it can be more than that and if you now multiply that time by the amount of assemblies your application may need, we are talking about more than that. But, that isn't even the performance benefit that I was referring to. If several programs use copies of the same assembly, EACH assembly will be loaded into memory. If those same programs were to use a GAC assembly, the assembly is loaded ONE time. Having to be an admin to install a program is nothing new and a benefit IMHO. Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> wrote in message news:u%239mGAgyGHA.3632@TK2MSFTNGP03.phx.gbl... >I just knew you would react on this :-) > > But i just hope he gets the point > > Groeten > > Michel > > > > "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schreef in bericht > news:OTkL$2fyGHA.2036@TK2MSFTNGP05.phx.gbl... >> Michel, >> >>>again : every advantage has a dissadvantage >> >> I thought Scott is an American, do you think he knows Johan Cruyff >> >> Cor >> >> > > > It is a discussion Michel. And so, I have the right to respond as I see No i do not , as i said i have the feeling that you were giving me no room > fit > (are you disagreeing with that?). to ventilate my opinion >If you took personal offense at my remark, I apologize, perhaps the Yes i did , and i accept your apolygee .>American term "rant" would have been more appropriate. > You originally wrote: "in all other situations it is a ticking time bomb This is my opinion still , in a perfect world it would not happen however > ( stay away of it as it were the plague )". the world isn`t perfect > Which is an absurd statement, based on no fact whatsoever. Since then, Well i did not find anny proof yet for your claimed performance benefit but > you have loosened your original stance a bit, but you still haven't > written anything that indicates to me that you truly (and more > importantly) understand the function of the GAC. One example would be > that on performance, you simply talk about the "nanosecond" quicker an > application may start. Well, I haven't measured myself, but I believe it > can be more than that and if you now multiply that time by the amount of > assemblies your application may need, we are talking about more than that. > But, that isn't even the performance benefit that I was referring to. If > several programs use copies of the same assembly, EACH assembly will be > loaded into memory. If those same programs were to use a GAC assembly, the > assembly is loaded ONE time. i will investigate this ( thought that this was happening with all signed assembly`s ) i might have learned something new > Having to be an admin to install a program is nothing new and a benefit Well having written programs for large organizations ( like the euromaster > IMHO. group ) that have a policy installed that my software can be installed without a administrator i know it is sometimes necesary Well i have to go to work now regards Michel Posseth [MCP] Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:eQzJDRhyGHA.1936@TK2MSFTNGP04.phx.gbl... > It is a discussion Michel. And so, I have the right to respond as I see > fit (are you disagreeing with that?). If you took personal offense at my > remark, I apologize, perhaps the American term "rant" would have been more > appropriate. > > You originally wrote: "in all other situations it is a ticking time bomb > ( stay away of it as it were the plague )". > > Which is an absurd statement, based on no fact whatsoever. Since then, > you have loosened your original stance a bit, but you still haven't > written anything that indicates to me that you truly (and more > importantly) understand the function of the GAC. One example would be > that on performance, you simply talk about the "nanosecond" quicker an > application may start. Well, I haven't measured myself, but I believe it > can be more than that and if you now multiply that time by the amount of > assemblies your application may need, we are talking about more than that. > But, that isn't even the performance benefit that I was referring to. If > several programs use copies of the same assembly, EACH assembly will be > loaded into memory. If those same programs were to use a GAC assembly, the > assembly is loaded ONE time. > > Having to be an admin to install a program is nothing new and a benefit > IMHO. > > > > "Michel Posseth [MCP]" <M***@posseth.com> wrote in message > news:u%239mGAgyGHA.3632@TK2MSFTNGP03.phx.gbl... >>I just knew you would react on this :-) >> >> But i just hope he gets the point >> >> Groeten >> >> Michel >> >> >> >> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schreef in bericht >> news:OTkL$2fyGHA.2036@TK2MSFTNGP05.phx.gbl... >>> Michel, >>> >>>>again : every advantage has a dissadvantage >>> >>> I thought Scott is an American, do you think he knows Johan Cruyff >>> >>> Cor >>> >>> >> >> > > You may want to take a look at the following articles that discuss pro's &
con's of the GAC, but do talk about GAC performance gains: http://msdn.microsoft.com/msdnmag/issues/06/05/CLRInsideOut/ (Look at the "Assemblies and the GAC" section, which discusses NGen, the GAC and start up time). http://blogs.msdn.com/kevin_ransom/archive/2004/05/28/143731.aspx http://www.gotdotnet.com/team/clr/when_to_use_the_gac.aspx Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> wrote in message news:ukIHjOmyGHA.5048@TK2MSFTNGP05.phx.gbl... > >> It is a discussion Michel. And so, I have the right to respond as I see >> fit >> (are you disagreeing with that?). > > No i do not , as i said i have the feeling that you were giving me no room > to ventilate my opinion > >>If you took personal offense at my remark, I apologize, perhaps the >>American term "rant" would have been more appropriate. > > Yes i did , and i accept your apolygee . > >> You originally wrote: "in all other situations it is a ticking time bomb >> ( stay away of it as it were the plague )". > > This is my opinion still , in a perfect world it would not happen however > the world isn`t perfect > >> Which is an absurd statement, based on no fact whatsoever. Since then, >> you have loosened your original stance a bit, but you still haven't >> written anything that indicates to me that you truly (and more >> importantly) understand the function of the GAC. One example would be >> that on performance, you simply talk about the "nanosecond" quicker an >> application may start. Well, I haven't measured myself, but I believe it >> can be more than that and if you now multiply that time by the amount of >> assemblies your application may need, we are talking about more than >> that. But, that isn't even the performance benefit that I was referring >> to. If several programs use copies of the same assembly, EACH assembly >> will be loaded into memory. If those same programs were to use a GAC >> assembly, the assembly is loaded ONE time. > > Well i did not find anny proof yet for your claimed performance benefit > but i will investigate this ( thought that this was happening with all > signed assembly`s ) > i might have learned something new > >> Having to be an admin to install a program is nothing new and a benefit >> IMHO. > > Well having written programs for large organizations ( like the euromaster > group ) that have a policy installed that my software can be installed > without a administrator i know it is sometimes necesary > > > > Well i have to go to work now > > regards > > Michel Posseth [MCP] > > > > "Scott M." <s-mar@nospam.nospam> schreef in bericht > news:eQzJDRhyGHA.1936@TK2MSFTNGP04.phx.gbl... >> It is a discussion Michel. And so, I have the right to respond as I see >> fit (are you disagreeing with that?). If you took personal offense at my >> remark, I apologize, perhaps the American term "rant" would have been >> more appropriate. >> >> You originally wrote: "in all other situations it is a ticking time bomb >> ( stay away of it as it were the plague )". >> >> Which is an absurd statement, based on no fact whatsoever. Since then, >> you have loosened your original stance a bit, but you still haven't >> written anything that indicates to me that you truly (and more >> importantly) understand the function of the GAC. One example would be >> that on performance, you simply talk about the "nanosecond" quicker an >> application may start. Well, I haven't measured myself, but I believe it >> can be more than that and if you now multiply that time by the amount of >> assemblies your application may need, we are talking about more than >> that. But, that isn't even the performance benefit that I was referring >> to. If several programs use copies of the same assembly, EACH assembly >> will be loaded into memory. If those same programs were to use a GAC >> assembly, the assembly is loaded ONE time. >> >> Having to be an admin to install a program is nothing new and a benefit >> IMHO. >> >> >> >> "Michel Posseth [MCP]" <M***@posseth.com> wrote in message >> news:u%239mGAgyGHA.3632@TK2MSFTNGP03.phx.gbl... >>>I just knew you would react on this :-) >>> >>> But i just hope he gets the point >>> >>> Groeten >>> >>> Michel >>> >>> >>> >>> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schreef in bericht >>> news:OTkL$2fyGHA.2036@TK2MSFTNGP05.phx.gbl... >>>> Michel, >>>> >>>>>again : every advantage has a dissadvantage >>>> >>>> I thought Scott is an American, do you think he knows Johan Cruyff >>>> >>>> Cor >>>> >>>> >>> >>> >> >> > > Dear Mr. Posseth, > Pleas investigate the true meanings of the term Dll
hell , people who > programmed and deployed Vb6 , Delphi etc etc applications on win32 will I wrote software in VB6...> know what i mean :-) > In the past when programmers dumped there dll`s in system32 we had lots of To me "DLL hell" means that I have several versions of DLLs in various > problems with versioning of dll`s ( we needed to write intelligent setup`s > and even then it sometimes broke another or your own app ) > With .Net we can just put the required dll`s in the assembly directory ( or > if you prefer and add a config entry in a sub directory below the assembly > dir ) directories. One thing is that it consumes unnecessary disk space, the other thing is that it is more difficult to support your software. Having one copy of a DLL in system32 is better than having 20 spread all over your hard drive. By definition, a higher version number has to be backward compatible. If you keep that in mind when updating your DLL, there is no "DLL hell". > however we talk about Xcopy deployment if you call that Dll hell well then Wikipedia says: "These difficulties include ... and having many > praise the lord you started ( probably ) with .Net > > http://en.wikipedia.org/wiki/DLL_hell unnecessary DLL copies." (same what I say) > The solution for your problem ?? ,,, is in my opinion to create a setup That's what I always do.> project for your proggy > In my opinion the GAC is only to be used with BL objects in corporate Why do you think it's a ticking time bomb?> environments , in all other situations it is a ticking time bomb ( stay > away of it as it were the plague ) Best Regards, HKSHK HKSHK,
If there was no DLL hell, a term that comes AFAIK from the VB classic area, than the term would not exist. In my idea it can as well not be seen without thinking too about the different classic VB runtimes. Just my thought, Cor Show quoteHide quote "HKSHK" <hk***@gmx.net> schreef in bericht news:44f15033$0$17888$9b622d9e@news.freenet.de... > Dear Mr. Posseth, > Pleas investigate the true meanings of the term Dll > hell , people who >> programmed and deployed Vb6 , Delphi etc etc applications on win32 >> will know what i mean :-) > > I wrote software in VB6... > >> In the past when programmers dumped there dll`s in system32 we had lots >> of problems with versioning of dll`s ( we needed to write intelligent >> setup`s and even then it sometimes broke another or your own app ) >> With .Net we can just put the required dll`s in the assembly directory >> ( or if you prefer and add a config entry in a sub directory below the >> assembly dir ) > > To me "DLL hell" means that I have several versions of DLLs in various > directories. One thing is that it consumes unnecessary disk space, the > other thing is that it is more difficult to support your software. > > Having one copy of a DLL in system32 is better than having 20 spread all > over your hard drive. By definition, a higher version number has to be > backward compatible. If you keep that in mind when updating your DLL, > there is no "DLL hell". > >> however we talk about Xcopy deployment if you call that Dll hell well >> then praise the lord you started ( probably ) with .Net >> >> http://en.wikipedia.org/wiki/DLL_hell > > Wikipedia says: "These difficulties include ... and having many > unnecessary DLL copies." (same what I say) > >> The solution for your problem ?? ,,, is in my opinion to create a setup >> project for your proggy > > That's what I always do. > >> In my opinion the GAC is only to be used with BL objects in corporate >> environments , in all other situations it is a ticking time bomb ( stay >> away of it as it were the plague ) > > Why do you think it's a ticking time bomb? > > Best Regards, > > HKSHK Hello mr hkshk , ( ?? )
> To me "DLL hell" means that I have several versions of DLLs in various No :> directories. One thing is that it consumes unnecessary disk space, the > other thing is that it is more difficult to support your software. The dll hell has everything to do with versioning of dll`s stored in one location ( system32 / GAC ) In the past i have seen much of my colegues send across europe to repair broken programs because there setup overwrote specific dll`s that were shared among other programs as a vb6 programmer you probaly are aware of the famous bootstrap error that could lead to endless restarting of the target computer because "some system files were out of date" ? XCOPY deployment takes care of the DLL hell because it ensures that all dependecies have been tested against the target assembly , this is even true when creating a update package that selectively only updates certain dll`s , cause you have tested the app with these dll`s > One thing is that it consumes unnecessary disk space Yes : that is true however with current computers this is not a problem ( those few kb`s of overhead or let`s do though with 20 progs 10 MB ??? what is the reliability of your program worth in harddisk space ) > other thing is that it is more difficult to support your software. No : it isn`t it makes things much harder , in your scenario you should have to test all previously deployed apps that use the same set of dll`s even better if you create an assembly that is used by third party`s , they should recheck there app to for bugs or unexpected behavior . > Having one copy of a DLL in system32 is better than having 20 spread all Well i and MS ( as they anounced that .Net is the solution for the above ) > over your hard drive. do not share this opinion >By definition, a higher version number has to be backward compatible. If True however we are only humans , and as good as we are we make mistakes , >you keep that in mind when updating your DLL, there is no "DLL hell". breaking something somewhere at some point could lead to a dissaster ( murphy`s law ,, anything that can go wrong will go wrong at some point, this is the ticking time bomb ) > Wikipedia says: "These difficulties include ... and having many I fully comply with that however i do not see this as a true problem as i > unnecessary DLL copies." (same what I say) said before how much harddisk space is the ensured stability of your program worth ? ( in most of the scenario`s probaly a few hundred kb`s , but if it were mb`s i wouldn`t even care ) Also another thing to consider is the following : The GAC does facilitate side-by-side storage of DLLs based on the assembly's strong identity (something that did not exist with system32), so what does this mean ? Lets say you have 10 applications that use the same foo.dll you do ten seperate upgrades for foo.dll when you release one of your projects well you now end up with ten versions of foo.dll in your GAC ? so were is your disk space saving now ?? even better now i deinstall one of the proggy`s in my scenario this is no problem cause i know what the deps are ,,, you might now have a problem as you can`t remove foo.dll unless you documented the exact usage and never missed one, so most safe is to leave the dll in the GAC so in the end you leave rubish on the computer while the XCOPY deployed app dissapears without a trace >> The solution for your problem ?? ,,, is in my opinion to create a setup Well then i don`t see your problem at all>> project for your proggy > > That's what I always do. However : Google on "when to use GAC" and see what other developers say about this subject , you will see that lots of them will tell you that GAC = reintroducing Dll hell there was even a rumour that the GAC will eventually dissapear because of this in future versions of the framework . If you are a corporate developer , and fit the "use the GAC scenario" or jou just think you are on the right track well then use the GAC my statements above and my previous posts are reflecting my opinion regarding this mather based on my knowledge and experience i know that in my situation deploying apps to thousands of users throughout Europe using the GAC is not a good idea . ps. I always thought that a fellow VB6 developer would love the Xcopy capability of VB.Net , as a VB6 developer i have written lots of complex setup`s and because of this fact i inmediatly loved the .Net ease of deployment . kind regards Michel Posseth [MCP] Show quoteHide quote "HKSHK" <hk***@gmx.net> schreef in bericht news:44f15033$0$17888$9b622d9e@news.freenet.de... > Dear Mr. Posseth, > Pleas investigate the true meanings of the term Dll > hell , people who >> programmed and deployed Vb6 , Delphi etc etc applications on win32 >> will know what i mean :-) > > I wrote software in VB6... > >> In the past when programmers dumped there dll`s in system32 we had lots >> of problems with versioning of dll`s ( we needed to write intelligent >> setup`s and even then it sometimes broke another or your own app ) >> With .Net we can just put the required dll`s in the assembly directory >> ( or if you prefer and add a config entry in a sub directory below the >> assembly dir ) > > To me "DLL hell" means that I have several versions of DLLs in various > directories. One thing is that it consumes unnecessary disk space, the > other thing is that it is more difficult to support your software. > > Having one copy of a DLL in system32 is better than having 20 spread all > over your hard drive. By definition, a higher version number has to be > backward compatible. If you keep that in mind when updating your DLL, > there is no "DLL hell". > >> however we talk about Xcopy deployment if you call that Dll hell well >> then praise the lord you started ( probably ) with .Net >> >> http://en.wikipedia.org/wiki/DLL_hell > > Wikipedia says: "These difficulties include ... and having many > unnecessary DLL copies." (same what I say) > >> The solution for your problem ?? ,,, is in my opinion to create a setup >> project for your proggy > > That's what I always do. > >> In my opinion the GAC is only to be used with BL objects in corporate >> environments , in all other situations it is a ticking time bomb ( stay >> away of it as it were the plague ) > > Why do you think it's a ticking time bomb? > > Best Regards, > > HKSHK "Michel Posseth [MCP]" <M***@posseth.com> schrieb: I don't think the DLL applies to the GAC or the Win32 Side-by-Side cache >> To me "DLL hell" means that I have several versions of DLLs in various >> directories. One thing is that it consumes unnecessary disk space, the >> other thing is that it is more difficult to support your software. > > No : > > The dll hell has everything to do with versioning of dll`s stored in one > location ( system32 / GAC ) because both support assembly versioning to prevent the versioning issues typically referred to as DLL Hell. Note that assemblies installed into the GAC must have a strong name which makes sure that no other vendor can publish a fix of an assembly. > In the past i have seen much of my colegues send across europe to repair Yep, that's the problem in Windows versions prior to Windows 2000 (which > broken programs because there setup overwrote specific dll`s that were > shared among other programs as a vb6 programmer you probaly are aware of > the famous bootstrap error that could lead to endless restarting of the > target computer because "some system files were out of date" ? came with Windows File Protection). Windows XP/Server 2003 even provide a mechanism for Win32 assemblies (Side-by-Side cache). > XCOPY deployment takes care of the DLL hell because it ensures that all Updates in contrast to new versions of an assembly don't break the > dependecies have been tested against the target assembly , this is even > true when creating a update package that selectively only updates certain > dll`s , cause you have tested the app with these dll`s compatibility. If they do, that's due to a mistake by the developer, which should not occur. The problem with installing each assembly used by an application into its application directory is that fixes for the assembly cannot be rolled out easily because it's not clear which application uses the DLL. Rememver the JPEG security hole in the GDI+ assembly. Microsoft had to release a separate tool that searches for this DLL on the system and patches installed versions. >> Having one copy of a DLL in system32 is better than having 20 spread all I believe Microsoft does only share the opinion for Win32 assemblies prior >> over your hard drive. > > Well i and MS ( as they anounced that .Net is the solution for the > above ) do not share this opinion to Windows XP/Server 2003. However, Windows XP/Server 2003 both come with the Side-by-Side cache ("%WINDIR%\WinSxS") which is an unmanaged counterpart to the GAC. > Google on "when to use GAC" and see what other developers say about this I would not consider multiple versions of the same DLL on the system as DLL > subject , you will see that lots of them will tell you that GAC = > reintroducing Dll hell > there was even a rumour that the GAC will eventually dissapear because of > this in future versions of the framework . Hell. DLL Hell describes versioning problems, not DLL redundancy on a system. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Show quote
Hide quote
"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> schreef in bericht When i pressed the submit button and reread the posting i was already afraid news:u1KM6hdyGHA.4972@TK2MSFTNGP03.phx.gbl... > "Michel Posseth [MCP]" <M***@posseth.com> schrieb: >>> To me "DLL hell" means that I have several versions of DLLs in various >>> directories. One thing is that it consumes unnecessary disk space, the >>> other thing is that it is more difficult to support your software. >> >> No : >> >> The dll hell has everything to do with versioning of dll`s stored in one >> location ( system32 / GAC ) > > I don't think the DLL applies to the GAC or the Win32 Side-by-Side cache > because both support assembly versioning to prevent the versioning issues > typically referred to as DLL Hell. Note that assemblies installed into > the GAC must have a strong name which makes sure that no other vendor can > publish a fix of an assembly. that this was unclear in my response you will see a few paragraphs below that i am aware of the versioning mechanism My aversion against the GAC is due to the fact that you are depending in the end on a reference count for every version to make sure that it is there and won`t break apps, my personal opinion is that it introduces unnecesay deployment complexity ( write an installer that delivers a file to the GAC to call one, need of administrator interference due to system ACL ) Most people use Gacutil.exe or Xcopy to deploy there assembly to the GAC while they should use a installer to do so because these do not provide assembly reference counting . Show quoteHide quote > Well you are right , however in the company`s i have worked for i wouldn`t >> In the past i have seen much of my colegues send across europe to repair >> broken programs because there setup overwrote specific dll`s that were >> shared among other programs as a vb6 programmer you probaly are aware of >> the famous bootstrap error that could lead to endless restarting of the >> target computer because "some system files were out of date" ? > > Yep, that's the problem in Windows versions prior to Windows 2000 (which > came with Windows File Protection). Windows XP/Server 2003 even provide a > mechanism for Win32 assemblies (Side-by-Side cache). > >> XCOPY deployment takes care of the DLL hell because it ensures that all >> dependecies have been tested against the target assembly , this is even >> true when creating a update package that selectively only updates certain >> dll`s , cause you have tested the app with these dll`s > > Updates in contrast to new versions of an assembly don't break the > compatibility. If they do, that's due to a mistake by the developer, > which should not occur. The problem with installing each assembly used by > an application into its application directory is that fixes for the > assembly cannot be rolled out easily because it's not clear which > application uses the DLL. Rememver the JPEG security hole in the GDI+ > assembly. Microsoft had to release a separate tool that searches for this > DLL on the system and patches installed versions. > bet my life on the fact that my collegues did not break the compatibility so i choose to be on the safe side . But to rephrase this, every advantage has a dissadvantage :-) >>> Having one copy of a DLL in system32 is better than having 20 spread all well>>> over your hard drive. >> >> Well i and MS ( as they anounced that .Net is the solution for the >> above ) do not share this opinion > > I believe Microsoft does only share the opinion for Win32 assemblies prior > to Windows XP/Server 2003. However, Windows XP/Server 2003 both come with > the Side-by-Side cache ("%WINDIR%\WinSxS") which is an unmanaged > counterpart to the GAC. < snip from MSDN developers guide > You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code. < snip from MSDN developers guide > i read this as : Xcopy deployment is the prefered way the mono dev group has it stated like this What Should Be Installed to the GAC Not all assemblies should be installed to the GAC. In fact apart from system assemblies very few assemblies should be installed to the GAC. Installing an assembly on the GAC involves a commitment to keep the API backwards compatible. If you are to break compatibility, you will have to change the version and ship and maintain as many copies as you have versions to avoid breaking existing applications. Here are the criteria an assembly should meet to be installed into the GAC: a.. Useful to more then one application - There is no point to sharing a assembly if only one application is going to use it. If a assembly is only used by one application or is very tightly coupled to an application side-by-side deployment is a better solution then the GAC b.. Only loads assemblies that are in the GAC - If your assembly loads or references assemblies that are not in the GAC it should not be installed to the GAC. c.. Commitment to maintain a backwards-compatible library, commitment to use different versions on API breakage - Unless your API is mature you really want to avoid using the GAC because you will make breaking changes or need to refactor your library. If you have existing users, the burden is on the user to install multiple versions of your library. If your library does not match the above criteria, or you are not in a position to guarantee backwards compatibility of the libraries at this time, you should encourage your users to link and develop against a particular version and to ship the library bundled with their software. > I think the term is often misused because the end result is the same , an >> Google on "when to use GAC" and see what other developers say about this >> subject , you will see that lots of them will tell you that GAC = >> reintroducing Dll hell >> there was even a rumour that the GAC will eventually dissapear because of >> this in future versions of the framework . > > I would not consider multiple versions of the same DLL on the system as > DLL Hell. DLL Hell describes versioning problems, not DLL redundancy on a > system. application that will not run because of a missing dependancy or doesn`t have the required interface or version The difference in thoughts we have is because you are probably a wishfull thinker ( positive aproach ) i am in contradiction a true pessimist if i have to forsee a problem in 2 scenario`s and one is postive and the other is negative i go for the negative version ( coder will commit himself to maintain compatibility is read by me as "Coder will in a point of time forget his commitment" and so break my app , solution i ship the required dll with my app ) JMO Michel Posseth [MCP] > Well you are right , however in the company`s i have worked for i wouldn`t I would never make an application more complex or degrade the performance > bet my life on the fact that my collegues did not break the compatibility > so i choose to be on the safe side . just so my collegue's code will work. Scott,
> I would never make an application more complex or degrade the performance That is in my idea the base for the private and public scope of members.> just so my collegue's code will work. Cor Not sure what you mean here Cor. What I meant was that I wouldn't go the
private assembly route just because other collegue's will have an easier time with this, when I know that it would make my application messier and perhaps slower. I'm not referring to members of a class (internal code) here. Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:%23DNlkHfyGHA.4176@TK2MSFTNGP06.phx.gbl... > Scott, > >> I would never make an application more complex or degrade the performance >> just so my collegue's code will work. > > That is in my idea the base for the private and public scope of members. > > Cor > > Scott,
But you wrote in your previous sentence >you would never make an application more complex or degrade the performance Is that not what Michel is in a way is doing, by protecting things he makes >just so my colleagues code will work. it easier for his colleagues to do things without to worry about not needed things. Therefore my analogy (maybe should I have written that by my sentence) to private and public scope of members. Cor Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:%230PNzTfyGHA.5048@TK2MSFTNGP05.phx.gbl... > Not sure what you mean here Cor. What I meant was that I wouldn't go the > private assembly route just because other collegue's will have an easier > time with this, when I know that it would make my application messier and > perhaps slower. I'm not referring to members of a class (internal code) > here. > > > "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message > news:%23DNlkHfyGHA.4176@TK2MSFTNGP06.phx.gbl... >> Scott, >> >>> I would never make an application more complex or degrade the >>> performance just so my collegue's code will work. >> >> That is in my idea the base for the private and public scope of members. >> >> Cor >> >> > > I think Michel is saying that sacraficing the security and performance
benefits offered (in some situations) by the GAC so that his collgue's don't have to write code correctly or understand versioning properly is acceptable, I disagree. Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:OkJatvfyGHA.4104@TK2MSFTNGP02.phx.gbl... > Scott, > > But you wrote in your previous sentence >>you would never make an application more complex or degrade the >>performance just so my colleagues code will work. > > Is that not what Michel is in a way is doing, by protecting things he > makes it easier for his colleagues to do things without to worry about not > needed things. Therefore my analogy (maybe should I have written that by > my sentence) to private and public scope of members. > > Cor > > "Scott M." <s-mar@nospam.nospam> schreef in bericht > news:%230PNzTfyGHA.5048@TK2MSFTNGP05.phx.gbl... >> Not sure what you mean here Cor. What I meant was that I wouldn't go the >> private assembly route just because other collegue's will have an easier >> time with this, when I know that it would make my application messier and >> perhaps slower. I'm not referring to members of a class (internal code) >> here. >> >> >> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message >> news:%23DNlkHfyGHA.4176@TK2MSFTNGP06.phx.gbl... >>> Scott, >>> >>>> I would never make an application more complex or degrade the >>>> performance just so my collegue's code will work. >>> >>> That is in my idea the base for the private and public scope of members. >>> >>> Cor >>> >>> >> >> > > Dear Scott,
Thanks a lot! That's exactly what I was looking for. Best Regards, HKSHK Scott M. wrote: Show quoteHide quote > Prepare your assembly with a strong name and register it into the Global > Assembly Cache (GAC). Then you can have several applications use it but > only maintain one copy that is in a central location. > > > "HKSHK" <hk***@gmx.net> wrote in message > news:44f050c8$0$24209$9b622d9e@news.freenet.de... > > Hello, > > > > I have this problem: > > I wrote some DLLs with VB.Net 2003 which I use with my programs. But I > > want to avoid that I have to go down to "DLL hell" and to copy all used > > dlls into each program directory. > > > > Does anyone have an idea how I can avoid that? > > > > Thanks in advance! > > > > Best Regards, > > > > HKSHK Another solution would be to install all the applications to one
subdirectory that holds all dependecies mark all the deps in your setup as shared the MSI will then create a usage count and will not remove the dll`s unless the last application was deinstalled regards Michel Posseth [MCP] Show quoteHide quote "HKSHK" <hk***@gmx.net> schreef in bericht news:1156620052.697989.264740@b28g2000cwb.googlegroups.com... > Dear Scott, > > Thanks a lot! That's exactly what I was looking for. > > Best Regards, > > HKSHK > > Scott M. wrote: >> Prepare your assembly with a strong name and register it into the Global >> Assembly Cache (GAC). Then you can have several applications use it but >> only maintain one copy that is in a central location. >> >> >> "HKSHK" <hk***@gmx.net> wrote in message >> news:44f050c8$0$24209$9b622d9e@news.freenet.de... >> > Hello, >> > >> > I have this problem: >> > I wrote some DLLs with VB.Net 2003 which I use with my programs. But I >> > want to avoid that I have to go down to "DLL hell" and to copy all used >> > dlls into each program directory. >> > >> > Does anyone have an idea how I can avoid that? >> > >> > Thanks in advance! >> > >> > Best Regards, >> > >> > HKSHK > 
Other interesting topics
Generic collection question
Are codes ran in try blocks expensive? DatagridView Column Headers books for vb.net Binding Data to Dataset or Table in VB, String '=' is two orders of magnitude slower than .Equals! how to make a mouseup event called only once during a double click event? DefaultValueAttribute And Array Properties sqlexpress WebBrowser Control Issue |
|||||||||||||||||||||||
