On May 17, 2012, at 4:45 AM, Stuart Lodge wrote: > Is there any point in putting in a support request for this to be changed? It > did seem to be working beautifully without this linking in the previous alpha.
Feel free to file a bug so that we can discuss the pros/cons of implicitly including referenced assemblies. :-) After playing around with how VS does things, I'm starting to understand that I've mis-remembered how VS does things...and I'm not entirely sure I like it. :-) For example, consider the solution with two projects, Lib and App, with Lib referencing System.Drawing.dll and App referencing Lib but _not_ System.Drawing.dll. The full closure of assemblies would thus be App.exe, Lib.dll, and System.Drawing.dll, but the question: will the App project need to reference System.Drawing.dll? The answer: Maybe. If Lib.dll has a public member that uses a type from System.Drawing.dll that App references, _then_ the App project also needs to reference System.Drawing.dll. If App.exe doesn't reference any such member, then the App project does not need to reference System.Drawing.dll. There's a certain bit of logic in there, but the end result is that if I'm looking at the App project, I have no actual idea what the entire set of assembly dependencies is, as many dependencies will be brought in implicitly from referenced projects. I remain unconvinced that pulling things in implicitly is a good thing for apps that need to be completely self-contained, which is the case for Mono for Android apps. ... Then I spoke with the MonoTouch team to see how they do things, and they have implicit dependencies. So there's that. Guess we should actually support implicit dependencies then. - Jon _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
