3 ms·

I'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, OD

I'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!

maartenba 13y ago
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).
- maartenba 13y ago
  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!
  - ygra 13y ago
    There's nothing technical that would prevent nuget from including MSBuild targets that are then picked up after installing the package, right? (Worst case would be that you'd have to use a wrapper project which gets the dependencies and then builds the actual project, in case project includes are handled before the nuget target.)
    - maartenba 13y ago
      True that! And I hope more SDK's are shipped in NuGet packages so we can define explicit dependencies instead of implicit ones.
  - profquail 13y ago
    It doesn't seem to have been widely publicized, but as of NuGet 2.5 it's been possible to include custom .targets files in NuGet packages which are automatically pulled into a project when the package is referenced: http://docs.nuget.org/docs/reference/support-for-native-projects http://docs.nuget.org/docs/reference/support-for-native-proj...
chton 13y ago
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.
- JonoW 13y ago
  I think they just need to separate out the tools from the libraries, within the SDKs, i.e. all libraries through NuGet, everything else can still be an Msi, as a dev will need things like emulators and VS tooling add-ins, but none of this is needed for build server just to build the project
  - chton 13y ago
    I whole-heartedly agree. It does create some danger there of mismatching versions between the tooling and the nuget packages. What do we do if the user has upgraded to a newer version of the package, but hasn't updated his emulator yet? Vice versa is somewhat easier to enforce, but either way it will require careful checking and notifying of the devs.
- mattmanser 13y ago
  https://www.nuget.org/packages/AWSSDK/ https://www.nuget.org/packages/AWSSDK/ https://www.nuget.org/packages/Box.V2/ https://www.nuget.org/packages/Box.V2/ https://www.nuget.org/packages/DeveloperForce.Common/ https://www.nuget.org/packages/DeveloperForce.Common/ https://www.nuget.org/packages/Atlassian.SDK/3.0.0-beta1 https://www.nuget.org/packages/Atlassian.SDK/3.0.0-beta1 Random enterprise names I picked out off the top of my head.
  - chton 13y ago
    Okay, valid point, some already do. But that doesn't change the case that _all_ of them should be doing it whenever possible.
xavierdecoster 13y ago
The point being made here is that although many new stuff is being shipped through NuGet, there are still way to many "implicit" dependencies to the stuff that gets shipped through SDKs, installers, vsix, etc. Setting up a build server is a good indicator really of all these "implicit" dependencies. File > New C# Project results in a csproj file containing references to MSBuild targets and binaries that supposedly are already installed on the system. While that's a valid assumption on a developer's machine, these dependencies are declared "implicitly". Why not make them explicit and reference the appropriate MSBuild targets and libs from .NET NuGet packages? (really whish .NET gets componentized and shipped through NuGet one day). NuGet package restore could then simply pull in all dependencies required to build the software.

maartenba 13y ago

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).

maartenba 13y ago
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!
- ygra 13y ago
  There's nothing technical that would prevent nuget from including MSBuild targets that are then picked up after installing the package, right? (Worst case would be that you'd have to use a wrapper project which gets the dependencies and then builds the actual project, in case project includes are handled before the nuget target.)
  - maartenba 13y ago
    True that! And I hope more SDK's are shipped in NuGet packages so we can define explicit dependencies instead of implicit ones.
- profquail 13y ago
  It doesn't seem to have been widely publicized, but as of NuGet 2.5 it's been possible to include custom .targets files in NuGet packages which are automatically pulled into a project when the package is referenced: http://docs.nuget.org/docs/reference/support-for-native-projects http://docs.nuget.org/docs/reference/support-for-native-proj...

chton 13y ago

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.

JonoW 13y ago
I think they just need to separate out the tools from the libraries, within the SDKs, i.e. all libraries through NuGet, everything else can still be an Msi, as a dev will need things like emulators and VS tooling add-ins, but none of this is needed for build server just to build the project
- chton 13y ago
  I whole-heartedly agree. It does create some danger there of mismatching versions between the tooling and the nuget packages. What do we do if the user has upgraded to a newer version of the package, but hasn't updated his emulator yet? Vice versa is somewhat easier to enforce, but either way it will require careful checking and notifying of the devs.
mattmanser 13y ago
https://www.nuget.org/packages/AWSSDK/ https://www.nuget.org/packages/AWSSDK/ https://www.nuget.org/packages/Box.V2/ https://www.nuget.org/packages/Box.V2/ https://www.nuget.org/packages/DeveloperForce.Common/ https://www.nuget.org/packages/DeveloperForce.Common/ https://www.nuget.org/packages/Atlassian.SDK/3.0.0-beta1 https://www.nuget.org/packages/Atlassian.SDK/3.0.0-beta1 Random enterprise names I picked out off the top of my head.
- chton 13y ago
  Okay, valid point, some already do. But that doesn't change the case that _all_ of them should be doing it whenever possible.

xavierdecoster 13y ago

The point being made here is that although many new stuff is being shipped through NuGet, there are still way to many "implicit" dependencies to the stuff that gets shipped through SDKs, installers, vsix, etc. Setting up a build server is a good indicator really of all these "implicit" dependencies. File > New C# Project results in a csproj file containing references to MSBuild targets and binaries that supposedly are already installed on the system. While that's a valid assumption on a developer's machine, these dependencies are declared "implicitly". Why not make them explicit and reference the appropriate MSBuild targets and libs from .NET NuGet packages? (really whish .NET gets componentized and shipped through NuGet one day). NuGet package restore could then simply pull in all dependencies required to build the software.