Deployment hell
-
<rant> Geeez .. My Setup won't deploy my plug-in dll correctly on one of our computers, and I am just struggling with the Side by Side concept. What A PITA. The manifest of my dll keeps wanting to include the debug CRT library, although I do not have any debug lib of any kind in it, and the InstallShit is so straightforward for embedding the VC8 dlls. And then manifests do not work for dlls but only applications, then why wonder why so many people binds everything statically ? :sigh: And of course, it works on my machine. :| This plenty _s***s_. The remedy to the dll hell is worse than the problem. </rant>
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb -
<rant> Geeez .. My Setup won't deploy my plug-in dll correctly on one of our computers, and I am just struggling with the Side by Side concept. What A PITA. The manifest of my dll keeps wanting to include the debug CRT library, although I do not have any debug lib of any kind in it, and the InstallShit is so straightforward for embedding the VC8 dlls. And then manifests do not work for dlls but only applications, then why wonder why so many people binds everything statically ? :sigh: And of course, it works on my machine. :| This plenty _s***s_. The remedy to the dll hell is worse than the problem. </rant>
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverbIf you think deployment on MS is difficult, you should try it on J2EE!
Cheers, Vikram.
"I will put my new found knolage to good use" - Captain See Sharp. "Every time Lotus Notes starts up, somewhere a puppy, a kitten, a lamb, and a baby seal are killed." - Gary Wheeler.
-
<rant> Geeez .. My Setup won't deploy my plug-in dll correctly on one of our computers, and I am just struggling with the Side by Side concept. What A PITA. The manifest of my dll keeps wanting to include the debug CRT library, although I do not have any debug lib of any kind in it, and the InstallShit is so straightforward for embedding the VC8 dlls. And then manifests do not work for dlls but only applications, then why wonder why so many people binds everything statically ? :sigh: And of course, it works on my machine. :| This plenty _s***s_. The remedy to the dll hell is worse than the problem. </rant>
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb -
Rage wrote:
hen why wonder why so many people binds everything statically ?
Just do it! Who cares about space if the program doesnt even run?
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out nowIs it only for the space ? Is it not a problem of memory collision as well (shared or not memory, ,...) ? Careful, we are very near to the programming question here :)
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb -
Is it only for the space ? Is it not a problem of memory collision as well (shared or not memory, ,...) ? Careful, we are very near to the programming question here :)
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverbRage wrote:
Is it not a problem of memory collision as well
Your process, your memory isn't it? Who is going to share that?
Rage wrote:
we are very near to the programming question here
I dont know enough of C/C++ for that to qualify as one, ever! ;P
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out now -
Is it only for the space ? Is it not a problem of memory collision as well (shared or not memory, ,...) ? Careful, we are very near to the programming question here :)
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverbRage wrote:
Careful, we are very near to the programming question here
So far I haven't seen anything near a programming question, just rants about Dll problems. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Is it only for the space ? Is it not a problem of memory collision as well (shared or not memory, ,...) ? Careful, we are very near to the programming question here :)
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverbTypically, only code and read only data segments are shared between processes through DLLs, unless you explicitly setup segments which state otherwise. Static libraries are neutral to the question of sharing between processes. Static linking would most likely have no impact on your application, unless the DLL is implementing fancy pansy global hooks.
-- Kein Mitleid Für Die Mehrheit
-
Is it only for the space ? Is it not a problem of memory collision as well (shared or not memory, ,...) ? Careful, we are very near to the programming question here :)
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverbI may be totally wrong here and if I am please someone correct me, but the difference and benefits of dynamic compared to static are: -Space as you mentioned. With dynamic linking only one copy of the file is necessary for x number of applications that would use it. Static linking would mean one copy per application that use it. -Library versions and updates. Don't dynamic allow you to just replace the old dll file with a new one without having to retouch or recompile your application. Statically linking to a library would require a new compile of your app if you want to release a new version of your library. I might be wrong or missing the point on something. Please do correct me anyone who knows better. I understand the differences between the two about what happens at compile time vs run time.....but what it means later on during the life and use of an application is not very clear.
Dewm Solo - Managed C++ Developer
-
I may be totally wrong here and if I am please someone correct me, but the difference and benefits of dynamic compared to static are: -Space as you mentioned. With dynamic linking only one copy of the file is necessary for x number of applications that would use it. Static linking would mean one copy per application that use it. -Library versions and updates. Don't dynamic allow you to just replace the old dll file with a new one without having to retouch or recompile your application. Statically linking to a library would require a new compile of your app if you want to release a new version of your library. I might be wrong or missing the point on something. Please do correct me anyone who knows better. I understand the differences between the two about what happens at compile time vs run time.....but what it means later on during the life and use of an application is not very clear.
Dewm Solo - Managed C++ Developer
Dewm Solo wrote:
without having to retouch or recompile your application
Yes , like we found out today with the .NET 2 that comes with VS2008, it broke our DAL generation app. They changed the way dataset are being 'emitted' to code. Lucky just had to move a few things around, but what happened if this was on a client site, and the client updated? KABOOM. I think static linking is always better.
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out now -
Dewm Solo wrote:
without having to retouch or recompile your application
Yes , like we found out today with the .NET 2 that comes with VS2008, it broke our DAL generation app. They changed the way dataset are being 'emitted' to code. Lucky just had to move a few things around, but what happened if this was on a client site, and the client updated? KABOOM. I think static linking is always better.
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out nowGeez...thanks for posting this. I just installed VS2008 this morning and transferred my projects from VS2005 to it. Everything seems fine for now, but I am in the process of testing them on client workstations. I'll be extra careful and see what happens. Thanks again! I agree with you up to some point with the static linking. It is much easier to use indeed and it's what I've been doing here for a while...cause my boss won't give me the proper time to develop a real set of tools for our software and get to use dynamic linking efficiently. I do suffer from this though and wish I could use dynamic linking. Why? Because everyone of our projects has little subtle needs that require sometimes changes to those libraries which means that right now we probably 7 or 8 different versions of those libraries out on customers workstations. One day I will have to fix something in one of those apps or have to add some features. I will then decide to upgrade their libraries and then...and only then ...will I realize that compatibility has been broken and that I need to change the application to fit the new libraries. I hate this...and I dread the day it'll happen. With dynamic libraries I would have to answer to the same interface which would have ensured backward compatibility. Of course I try with my current static libraries, but there is no ensuring of it and eventually changes will occur...as they have in the past. Sometimes I really feel like static linking is the easy way out...the one that always comes back to bite you in the 'rear end'.
Dewm Solo - Managed C++ Developer
-
Geez...thanks for posting this. I just installed VS2008 this morning and transferred my projects from VS2005 to it. Everything seems fine for now, but I am in the process of testing them on client workstations. I'll be extra careful and see what happens. Thanks again! I agree with you up to some point with the static linking. It is much easier to use indeed and it's what I've been doing here for a while...cause my boss won't give me the proper time to develop a real set of tools for our software and get to use dynamic linking efficiently. I do suffer from this though and wish I could use dynamic linking. Why? Because everyone of our projects has little subtle needs that require sometimes changes to those libraries which means that right now we probably 7 or 8 different versions of those libraries out on customers workstations. One day I will have to fix something in one of those apps or have to add some features. I will then decide to upgrade their libraries and then...and only then ...will I realize that compatibility has been broken and that I need to change the application to fit the new libraries. I hate this...and I dread the day it'll happen. With dynamic libraries I would have to answer to the same interface which would have ensured backward compatibility. Of course I try with my current static libraries, but there is no ensuring of it and eventually changes will occur...as they have in the past. Sometimes I really feel like static linking is the easy way out...the one that always comes back to bite you in the 'rear end'.
Dewm Solo - Managed C++ Developer
Dewm Solo wrote:
I'll be extra careful and see what happens.
I doubt there will be problems, from what I can see the generated code for the DataSet is now utilizing a protected member, as I was moving the generated DataTable outside the DataSet class declaration, this caused a problem. VS2008 has been very good so far :)
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out now