Building .NET projects is a world of pain and here's how we should solve it
blog.maartenballiauw.be
Building .NET projects is a world of pain and here's how we should solve it
1–10 of 49 posts
Re: Building .NET projects is a world of pain and here's how we should solve it
#2You're right, we need to fix the sdk's as well to tackle dll hell.
Re: Building .NET projects is a world of pain and here's how we should solve it
#3This is something Microsoft needs to push instead of the insane MSI stuff. Microsoft really needs an officially sanctioned dependency manager, maybe NuGet. Something with a standardized package format based on _archives_, not _executable installers_.
The Microsoft ecosystem is light years behind OSS in this regard. Heck, CPAN was designed in 1993 and became available in 1997. Truly light years - CPAN predates the dot-com boom.
Re: Building .NET projects is a world of pain and here's how we should solve it
#4This is something Microsoft needs to push instead of the insane MSI stuff. Microsoft really needs an officially sanctioned dependency manager, maybe NuGet. Something with a standardized package format based on _archives_, not _executable installers_. The Microsoft ecosystem is light years behind OSS in this regard. Heck, CPAN was designed in 1993 and became available in 1997. Truly light years - CPAN predates the dot…
The good CPAN times :-) It was a bit of a cumbersome thing to work with as a newbie back then but at least it handled dependencies very well.
Re: Building .NET projects is a world of pain and here's how we should solve it
#5I'm not really sure what point you're trying to make. This seems to be exactly where MS are moving to with nuget.
Like all the new stuff, the WebAPIs, EF 6, OData, etc. is now being published as NuGet packages instead of installers or SDKs or whatever.
NuGet seems to be a direct response to this very issue and you constantly mention it.
So what are you asking? After all they can't change the past!
Re: Building .NET projects is a world of pain and here's how we should solve it
#6I'm not really sure what point you're trying to make. This seems to be exactly where MS are moving to with nuget. Like all the new stuff, the WebAPIs, EF 6, OData, etc. is now being published as NuGet packages instead of installers or SDKs or whatever. NuGet seems to be a direct response to this very issue and you constantly mention it. So what are you asking? After all they can't change the past!
That is not entirely true. For example the Windows Azure SDK has to be installed. Database tools have to be installed if you want to be able to compile a database project. There are many of the new things that do not follow this approach (hopefully: yet).
Re: Building .NET projects is a world of pain and here's how we should solve it
#7NuGet gets the job done admirably, but it was simply introduced too late; nearly 10 years after the introduction of .NET.
It's good to see NuGet has gained traction very quickly, but there are still plenty of projects predating NuGet that have solved the dependency management problem in their own unique way. Migrating all of those to NuGet takes time and willing maintainers.
Re: Building .NET projects is a world of pain and here's how we should solve it
#8This is something Microsoft needs to push instead of the insane MSI stuff. Microsoft really needs an officially sanctioned dependency manager, maybe NuGet. Something with a standardized package format based on _archives_, not _executable installers_. The Microsoft ecosystem is light years behind OSS in this regard. Heck, CPAN was designed in 1993 and became available in 1997. Truly light years - CPAN predates the dot…
The good CPAN times :-) It was a bit of a cumbersome thing to work with as a newbie back then but at least it handled dependencies very well.
In many ways CPAN is still state of the art. It has first-class support for namespacing and mirroring, which appears to still elude most environments' packaging systems.
And I'm saying this as someone that dislikes Perl a lot.
Re: Building .NET projects is a world of pain and here's how we should solve it
#9I'm not really sure what point you're trying to make. This seems to be exactly where MS are moving to with nuget. Like all the new stuff, the WebAPIs, EF 6, OData, etc. is now being published as NuGet packages instead of installers or SDKs or whatever. NuGet seems to be a direct response to this very issue and you constantly mention it. So what are you asking? After all they can't change the past!
Microsoft is increasingly doing it with their frameworks and components, but not for real SDKs. Windows 8 and Phone development still requires an installer to build.
It's not just Microsoft though. Other vendors need to jump on the same bandwagon. Right now, almost nobody really does, definitely nobody who sells to the enterprise market.
Re: Building .NET projects is a world of pain and here's how we should solve it
#10I'm not really sure what point you're trying to make. This seems to be exactly where MS are moving to with nuget. Like all the new stuff, the WebAPIs, EF 6, OData, etc. is now being published as NuGet packages instead of installers or SDKs or whatever. NuGet seems to be a direct response to this very issue and you constantly mention it. So what are you asking? After all they can't change the past!
That is not entirely true. For example the Windows Azure SDK has to be installed. Database tools have to be installed if you want to be able to compile a database project. There are many of the new things that do not follow this approach (hopefully: yet).
Added a P.S. to the post to reflect this: P.S.: A lot of the new packages like ASP.NET MVC and WebApi, the OData packages and such are being shipped as NuGet packages which is awesome. The ones that I am missing are those that require additional build targets that are typically shiipped in SDK's. Examples are the Windows Azure SDK, database tools and targets, ... I would like those to come aboard the NuGet train!