Problems with Resharper SDK nuget package

I'm having a few problems with the fact that the nuget package for Resharper's SDK is a huge mess of dlls (140mb).

I posted this recently on stackoverflow:
http://stackoverflow.com/questions/23135664/tfs-build-custom-activity-requiring-more-assemblies-than-needed

I had to checkin the whole sdk, which amounts to 80mb of dlls, to the TFS source control custom assemblies path so that I could finally use my modified workflow.

Have you guys thought about splitting this huge nuget package in manageable parts? How can someone reference it and carry such an enourmous amount of useless unrelated dlls? I mean, in my case, I only needed a very small subset of them to achieve what I wanted.

Also, have you thought about creating a .Net4.5 version of that package? I see it uses things like AsyncBridge for compatibility with .Net4 for instance, but I would like to avoid that since my project is 4.5.

And lastly, why are some external dependencies of your SDK not dependencies on the package? AsyncBridge for instance is available as a separate package. Why did you include it in your own package instead of saying your package depends on it? The same can be said for other dlls in there, like DevExpress, WpfContrib. Also, what is nunit doing here? I see you are shipping some UnitTests dlls in there too....

I'm sorry, but there are so many bad practices here that it is hard to believe the package came from you guys. Was this all really intentional?

Regards,
Juliano

2 comments
Comment actions Permalink

Hi Juliano!

I posted this recently on stackoverflow:
http://stackoverflow.com/questions/23135664/tfs-build-custom-activity-requiring-more-assemblies-than-needed


I've answered you on SO, but repeat some answers here.

I had to checkin the whole sdk, which amounts to 80mb of dlls, to the TFS source control custom assemblies path so that I could finally use my modified workflow.


For building process on CI server you do not need to checkin binaries to VCS. Use NuGet restore package functionality.
For using it on TFS you do need all binaries of CLT on server. It's smaller then ReSharper SDK, since do not contains
PDB information and all VS integration stuff. But, still about 20 Mb. That the payment for rich functionality.

Have you guys thought about splitting this huge nuget package in manageable parts? How can someone reference it and carry such an enourmous amount of useless unrelated dlls? I mean, in my case, I only needed a very small subset of them to achieve what I wanted.


Yes, we did. And in upcoming 9.0 release we are planing to do it.

Also, have you thought about creating a .Net4.5 version of that package? I see it uses things like AsyncBridge for compatibility with .Net4 for instance, but I would like to avoid that since my project is 4.5.


Yes, that problem is also on our radar.

And lastly, why are some external dependencies of your SDK not dependencies on the package? AsyncBridge for instance is available as a separate package. Why did you include it in your own package instead of saying your package depends on it? The same can be said for other dlls in there, like DevExpress, WpfContrib. Also, what is nunit doing here? I see you are shipping some UnitTests dlls in there too....


That's is also known issue. There are some problems with assemblies referencing.
We do not do it standard way, we have have custom targets files with some magic.
If we reference that dependent packages standard way it will bring standard assembly references which is something is
not good for us. But, we are looking at this problem too.

Slava.

0
Comment actions Permalink

Very thorough explanations Slava, I appreciate it.

I've commented on SO but I feel this is useful information to have on both places, so:

About the .Targets solution, I still fail to see how this will solve our problem, since it will require developers to unzip the CLT in some hardcoded folder and then use that folder to include the .Targets file in our projects.

Perhaps ideally another nuget package would be available that contained only what the InspectCode functionality needs and then it would be possible to share this across our team. I think that if I need to hardcode various paths to make this work, I'll end up using the custom activity solution still.

I'm sorry if my previous message felt insulting in any way (reading it again I feel I was a bit harsher than needed). When I noticed the SDK package had a bunch of other packages inside I immediately though it was a very bad practice but did not consider the fact that you for some reason can't directly reference them and such. It's very cool to see you guys are already considering refactors in there, I was surprised all my points were already been taken care of.

Again, thanks a lot for the prompt response Slava. I'm curious to know about how I should be distributing the targets file without hardcoding paths and such.
Juliano

0

Please sign in to leave a comment.