Why external .DLLs sucks today
-
We save all of our source code to a TFS server. TFS takes into consideration only the items included in project (seems rather normal). Well, a collegue of mine right now is on hollidays. Other collegue: "vonb (real name withhold), where is the epplus.dll? Is it .net?" Me: it's an external .dll. Other collegue: "Why can't I find it anywhere?" Me: did you take the code from TFS? Other collegue: "Yes, I did" Me: Then it's clear. External .DLL is not in GAC. Solution: had to go on the test server, go into the INETPUB\BLABLABLA\bin directory, and there it was. saved. Now the .DLL is included into the project and is in TFS. epplus is really nice to handl excel spreadsheets in a web app, so.
The signature is in building process.. Please wait...
You can setup NuGet to automatically download any missing dependencies. I don't put any third party libraries into source control, I just use NuGet. If it's a .dll that isn't available through nuget.org, then, as one other poster said, you can set up your own NuGet feed, either in the cloud through myget.org, or on your own server.
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup The world is going to laugh at you anyway, might as well crack the 1st joke! My code has no bugs, it runs exactly as it was written.
-
We save all of our source code to a TFS server. TFS takes into consideration only the items included in project (seems rather normal). Well, a collegue of mine right now is on hollidays. Other collegue: "vonb (real name withhold), where is the epplus.dll? Is it .net?" Me: it's an external .dll. Other collegue: "Why can't I find it anywhere?" Me: did you take the code from TFS? Other collegue: "Yes, I did" Me: Then it's clear. External .DLL is not in GAC. Solution: had to go on the test server, go into the INETPUB\BLABLABLA\bin directory, and there it was. saved. Now the .DLL is included into the project and is in TFS. epplus is really nice to handl excel spreadsheets in a web app, so.
The signature is in building process.. Please wait...
External dependencies have always sucked (DLL hell anyone?), but are a necessary evil... X|
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
We save all of our source code to a TFS server. TFS takes into consideration only the items included in project (seems rather normal). Well, a collegue of mine right now is on hollidays. Other collegue: "vonb (real name withhold), where is the epplus.dll? Is it .net?" Me: it's an external .dll. Other collegue: "Why can't I find it anywhere?" Me: did you take the code from TFS? Other collegue: "Yes, I did" Me: Then it's clear. External .DLL is not in GAC. Solution: had to go on the test server, go into the INETPUB\BLABLABLA\bin directory, and there it was. saved. Now the .DLL is included into the project and is in TFS. epplus is really nice to handl excel spreadsheets in a web app, so.
The signature is in building process.. Please wait...
This is a problem I used to run into a lot. I don't know if it's the best way, but the way I always deal with this problem is to put all my 3rd party DLLs (and even internal DLL references) in their own folder structure and include it as part of the solution. I usually just make solution folders for this. When you add references, make sure you reference the files there and not anything out of the GAC. Usually you don't even have to install the 3rd party libraries this way so I think it works pretty well. It also helps deal with version incompatibilities since you know everyone will be using whatever is in TFS and not installed on their machine.
-
You can setup NuGet to automatically download any missing dependencies. I don't put any third party libraries into source control, I just use NuGet. If it's a .dll that isn't available through nuget.org, then, as one other poster said, you can set up your own NuGet feed, either in the cloud through myget.org, or on your own server.
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup The world is going to laugh at you anyway, might as well crack the 1st joke! My code has no bugs, it runs exactly as it was written.
That does solve the DLL deployment problem rather nicely, which was the original poster's issue. However, it still leaves the issue of incompatible DLL versions unaddressed. Checking the DLL into revision control solves both issues, as well as providing a way to roll a new, incompatible DLL out to all the developers with minimal disruption. That's why revision control will continue to be my solution of choice to this issue.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
What about setting up your own NuGet feed?
Eagles may soar, but weasels don't get sucked into jet engines
This is exactly what my company's currently considering and why we're considering it :) prior to this we had a build folder called "ExternalDependencies" and then a Promotions file that was processed by a home-grown MSBuild orchestrator. You doctored your file to say what external dependencies you needed and they were pulled in at build time (both in IDE and on server) from the correct place in source control.
-
That does solve the DLL deployment problem rather nicely, which was the original poster's issue. However, it still leaves the issue of incompatible DLL versions unaddressed. Checking the DLL into revision control solves both issues, as well as providing a way to roll a new, incompatible DLL out to all the developers with minimal disruption. That's why revision control will continue to be my solution of choice to this issue.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
Yes, but you can specify versions with NuGet. And if you create your own feed, then you upload only the version you are using to your personal feed. Need to update it? Just upload the new version, and everyone can pull down the latest with a simple command. Then again, as usual, there is more than one solution to every problem! So, it's all good...whatever works best for you is the thing to do.
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup The world is going to laugh at you anyway, might as well crack the 1st joke! My code has no bugs, it runs exactly as it was written.
-
Yes, but you can specify versions with NuGet. And if you create your own feed, then you upload only the version you are using to your personal feed. Need to update it? Just upload the new version, and everyone can pull down the latest with a simple command. Then again, as usual, there is more than one solution to every problem! So, it's all good...whatever works best for you is the thing to do.
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup The world is going to laugh at you anyway, might as well crack the 1st joke! My code has no bugs, it runs exactly as it was written.
By the time you make it work with multiple views of different vintages seamlessly for all your developers, and make it easy for them to switch working with different views which need different revisions of the DLL, you've pretty much recreated what the revision control system does for you.. except some of it is manually maintained. However, like you said, whatever works :) Amusingly, I used to work for a company where we seriously discussed wrapping a physical computer in static mylar and checking it into the physical part revision tracking storeroom. It was the only way to guarantee we could build the old code. Ahh.. the bad old days.. they won't be missed :)
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
You could add a folder to solution called ThirdPartyDlls and dump it there.
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
We do exactly this. Kind of a pain when setting up new solutions, but it allows you to get latest and build on a new image w/o any headaches.
-
We save all of our source code to a TFS server. TFS takes into consideration only the items included in project (seems rather normal). Well, a collegue of mine right now is on hollidays. Other collegue: "vonb (real name withhold), where is the epplus.dll? Is it .net?" Me: it's an external .dll. Other collegue: "Why can't I find it anywhere?" Me: did you take the code from TFS? Other collegue: "Yes, I did" Me: Then it's clear. External .DLL is not in GAC. Solution: had to go on the test server, go into the INETPUB\BLABLABLA\bin directory, and there it was. saved. Now the .DLL is included into the project and is in TFS. epplus is really nice to handl excel spreadsheets in a web app, so.
The signature is in building process.. Please wait...
Might note of course that it doesn't get into the GAC accidentally. The following cases probably exist. - Consumer software where the third party product must be acquired by the user. - Consumer software where the installer uses the third party product installer and it puts it in the GAC (and that is the only option.) - All others. For all others the dll shouldn't be in the GAC at all. Some products install themselves there but the solution to that is to install, grab the dll, then uninstall. Some products have separate tools that seem to require the GAC, but that is still a variation of the first case except the developer responsible for the tool should be aware that they are using the GAC. Once you have the library it goes in source control like anything else. Tricks used to externalize library downloads as part of the build can be risky. Sometimes extremely so. For example. - A library is used in multiple projects. But the developer only tests the project they are working on (especially true to with many products) but the auto update updates everything. And breaks everything. - The build is not including everything so it fails when installed into the production server, in odd and unexpected ways. - The external source disappears or is unavailable. - Because of problems developers start hacking solutions to get around problems that they don't understand due to deadlines and missing libraries. Thus they end up doing things like building on the production server because that is the only way they know to get a build that works.
-
This is exactly what my company's currently considering and why we're considering it :) prior to this we had a build folder called "ExternalDependencies" and then a Promotions file that was processed by a home-grown MSBuild orchestrator. You doctored your file to say what external dependencies you needed and they were pulled in at build time (both in IDE and on server) from the correct place in source control.