Question

In a way I am looking for best-practice here.

I have a common project that is shared by many of my apps. This project has FlurryAnaylics and the ATMHud DLLs as references.

If I do not also reference these DLLs in the main project, the apps will often, but not always, fail in the debug-to-device test. In the debug-to-simulator I don't need to add these DLLs to the main project.

So, the question is: Do I have to include references to DLLs in the main project that I have in sub projects all the time?

Was it helpful?

Solution

Whenever possible I use references to project files (csproj files) over references to assemblies (.dll). It makes a lot of things easier, like:

  • code navigation (IDE);
  • automatic build dependency (the source code you're reading is the one you're building, not something potentially out-of-sync);
  • source-level debugging (even if you can have it without it, you're sure to be in-sync);
  • (easier) switch between Debug|Release|... configurations;
  • changing defines (or any project-level option);

E.g.

Solution1.sln

  • Project1a.csproj
  • MonoTouch.Dialog.csproj (link to ../Common/MonoTouch.Dialog.csproj)

Solution2.sln

  • Project2a.csproj
  • MonoTouch.Dialog.csproj (link to ../Common/MonoTouch.Dialog.csproj)

Common.sln

  • MonoTouch.Dialog.csproj

Large solutions might suffer a bit from doing this (build performance, searching across files...). The larger they get the less likely everyone has to know about every part of it. So there's a diminished return on the advantages while the inconvenience grows with each project being added.

E.g. I would not want to have references to every framework assemblies inside Mono (but personally I could live with all the SDK assemblies of MonoTouch ;-)

Note: Working with assemblies references should not cause you random errors while debugging on device. If you can create such a test case please fill a bug report :-)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top