Hi DevEx Team!
For the integration into several build services it would be absolutly amazing to provide nuget packages from the DevEx Assemblies provided by the installer (or as a seperated zip file) to use them to in an internal nuget package location.
So we not have to checkin the according dll's into our repo and are able to build every version checked in independent of the currently installed DevEx version.
i have no problem to create the nuget packages on my own, but i can't figure out any documentation which dependencies the components have on each other.
I think i am not the only one who likes to keep his repository kept clean (without binary merges).
We are not able to install the DevEx components on each build controller (we plan to use TeamFoundation Service / TeamFoundation Server).
With NuGet we could manage this in an easy way, without the pain of registering dll's in GAC. I think your licence agreements wouldn't be harmed.
Currently we use Jenkins and have multible versions of DevEx Components running. There can only be one Minor release at a time (12.2.4 eg. 12.2.5 is not possible at a time. We cant provide each DevEx version a dedicated build server instance to manage all the different versions.
Our developers currently are removing all the version information inside the *.csproj files. For example(, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b88d1754d700e49a, processorArchitecture=MSIL") and reinstall previous version each time they try to reproduce an error in production with according DevEx version.
With NuGet the build itself will handle the different versions of the dll's tracked in the nuget packages.config checked in.
I'm glad to hear from you,
We discussed this topic earlier in ticket S139898 (NuGet Packages). We do not have immediate plans to deliver our binaries as NuGet packages in contrast to our own installation engine. However, things change and we will possibly reconsider our position. Thank you for your ideas!