5 ms·
1.5 decades. Very impressive achievement. I am wondering though, and I will ask the question of all the .Net developers out there - Did Microsoft achieve thei
by cyberferret 10y ago
1.5 decades. Very impressive achievement.
I am wondering though, and I will ask the question of all the .Net developers out there - Did Microsoft achieve their end goal of reducing "DLL Hell" via the .Net framework?
I didn't do a lot of development in this platform, but whenever I dabbled in it, I used to come across the same sort of issues - "Oh, you PC doesn't have the correct version of the .Net framework installed, I'll have to go and download version x from Microsoft". There were a lot of applications tied to a particular (older) version of .NET and I remember that installing older versions over newer ones used to cause issues on quite a few network systems.
Also, got really tired of finding nice 'little' apps on the ancient web which looked like useful utilities in a 200Kb file, only to find out after downloading that you needed to then download a 100MB+ behemoth framework version x just to run it.
I know in a lot of cases in made development life easier, but on the deployment and implementation side of things, I feel we still suffered the same "DLL Hell", though not to the same level.
- pjmlp 10y ago> Did Microsoft achieve their end goal of reducing "DLL Hell" via the .Net framework? Yes, because the dynamic linker has the concept of versions. So it will only link if the right libraries are present in the system. In theory it is not possible to use the wrong version as it used to happen with DLLs and COM libraries. In practice, it requires the developers to actually care to version their libraries so that this works. Quite a few devs, just let the same version numbers as on the project template, or change them to mean whatever version is installed, thus getting back to the old behavior. When using libraries from devs that actually bother to change the version numbers properly, the problem is sorted out. edit: typo
- moomin 10y agoI'd say it's a mostly solved problem, if only because everyone uses their own versions of assemblies. ClickOnce is solid (if you automate the fiddly bits). There's more upfront checks than with Java, but that's more of a trade-off than a positive or negative.
- tonyedgecombe 10y agoI've been shipping .Net desktop apps for about five years now, I've never had a complaint about installing the framework, it isn't an issue anymore.
- NKCSS 10y agoTry C++/CLI :) Had that problem recently when I assumed .NET was installed, but it needed a separate C++ runtime for C++/CLI
- tonyedgecombe 10y agoI think I'll skip that :) One of the reasons I switched to C# was to move away from C++.
- jsmeaton 10y agoShipping c++ redistributable libraries is a major PITA. I couldn't figure out how to bundle them with a clickonce or wix installer.
- NKCSS 10y agoIt's not just that; everything feels old and fragile when you mess with C++(/CLI); I was amazed I had to write a stupid post-build event just to copy the app.config to the build dir... why is the experience so different from when you use C#? When doing .NET stuff, it would be nice if those things would be the same.
- kohanz 10y agoI did this once at a previous job. Was able to bundle all of the installers (including C++ redistributable, driver updates, etc.) into a single installer that ran off a single click, first in a Setup & Deployment project and then ported to Wix. It wasn't fun, but once it worked it saved us a ton of headaches in the field.
- snuxoll 10y agoI really need to figure out an easy way to bundle the C++ redist's with Wix myself, I've got a PowerShell module I've packaged up along with a MSM containing a vendor SDK it uses. Problem is, said SDK has native components so the VC++2015 runtime also needs to be installed. I deploy this using Ansible anyway so I am able to just install the C++ runtime separately, but it's a huge pain when I want someone to be able to double click an MSI on their developer machine and have it not work.
- piyush_soni 10y agoMost of the problems 'used to be' the case when .net was still young (like the first 2-5 years). I never see those problems anymore.