The NCrunch.Framework wiki page suggests copying NCrunch.Framework.dll from the GAC into the project's folder to prevent the build from breaking on machines that don't have NCrunch installed. While the solution works, it just doesn't feel right since NuGet was released; why not add the assembly to NuGet? It'll allow existing users to take advantage of NuGet features like automatic package restoration and update detection, and might catch the attention of potential new users browsing through the NuGet repo.
P.S. Thanks for an awesome plug-in ;)
Remco NCrunch Developer
#1149
13 Feb 2012 20:47 UTC
Hi Rory,
Thanks for posting! I've been considering placing this DLL under nuget. My main concern is that it needs to be versioned alongside the installation of NCrunch consuming it, otherwise many of the features activated by it may not actually work.
I'm glad your enjoying the tool :)
Thanks for posting! I've been considering placing this DLL under nuget. My main concern is that it needs to be versioned alongside the installation of NCrunch consuming it, otherwise many of the features activated by it may not actually work.
I'm glad your enjoying the tool :)
The same problem would arise when more than one person are sharing a solution as well, so I'm not sure how that affects the decision to use NuGet.
Remco NCrunch Developer
#1161
16 Feb 2012 08:22 UTC
You are absolutely correct. And giving more space for people to create version inconsistencies will only make this worse...
It may be the best solution would be to make the NCrunch.Framework code a bit smarter so that it can warn about version inconsistencies. I'll have a think about it.
It may be the best solution would be to make the NCrunch.Framework code a bit smarter so that it can warn about version inconsistencies. I'll have a think about it.
Respectfully, I don't see how putting the assemblies on NuGet "will only make this worse".
People "create version inconsistencies" by upgrading NCrunch to the next version, NOT by referencing a new Framework version. The framework version is only going to be updated when the NEW version of NCrunch stops working with the OLD Framework DLL. If you are trying to prevent inconsistencies altogether, the *only way* to do so is to stop releasing new versions.
If it were me, I would trust people to be able to keep NuGet packages in sync much more than I would trust them to manually manage DLLs by extracting them from the GAC.
People "create version inconsistencies" by upgrading NCrunch to the next version, NOT by referencing a new Framework version. The framework version is only going to be updated when the NEW version of NCrunch stops working with the OLD Framework DLL. If you are trying to prevent inconsistencies altogether, the *only way* to do so is to stop releasing new versions.
If it were me, I would trust people to be able to keep NuGet packages in sync much more than I would trust them to manually manage DLLs by extracting them from the GAC.
Post a reply
Log in to reply.