Yeah, though you should be able to switch that off with CopyLocal=false in the <Reference> (haven't tested if you can apply a condition on that). For me, the burden of having multiple .csproj files would outweigh a simple cleanup of undesired DLLs, but that's of course different for everyone :) -- Alex > From: edward.harvey.m...@clevertrove.com > To: alex.koeplin...@outlook.com > Subject: RE: [Mono-dev] Mono.Posix Cross Compiling > Date: Tue, 6 Jan 2015 19:48:06 +0000 > > > From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com] > > > > Why wouldn't the reference with HintPath compile on Mono? > > I just tried it out by adding the Mono.Security NuGet package > > (https://www.nuget.org/packages/Mono.Security/) to a simple console app, > > i.e. it added the HintPath to the packages folder, and it compiled fine in > > VS > > and MonoDevelop. > > Oh - My mistake. Yes it builds, but... > > The desired behavior is to provide Mono.Security.dll to the windows project, > and distribute the dll with the binary release product, while ignoring the > Mono.Security.dll in the source directory when built for mac or linux, use > the version of Mono.Security.dll that's provided by the target runtime OS. > > When I use the <Reference> including <HintPath>, then the dll from my source > tree gets copied to the build destination and distributed with the built > product. It might be possible to do something like a post-build script that > removes Mono.Security.dll from the build dir if this isn't a windows build... > But if we go that route, we're just trading one hack for another. The > different .sln and .csproj files is a hacky solution, but it's a solution. > > I like Timotheus's solution of generating the .sln and .csproj files > dynamically.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
