Internal method code reuse

Let's say you have 2 totally separate projects: Project 1 and Project 2. One is a Windows app, and one is a web app.

If both projects need classes A, B and C for their own internal use, what is the best way of promoting code reuse in the classes between the two projects (esp. as the code is updated over time)?

• Force the classes to be public, break the tidy public interface and make a reference from one proj开发者_如何学Goect to the other (yuck!)
• Create a third project for the shared components, and then use them only internally for the main projects (yuck!)
• "Add" the classes from project 1 to project 2 (going outside the project folder) and accept that project 2 will not have all the classes it needs to build within its project folder (acceptable, but not ideal)
• Depend on copy-and-paste, source code control cross-references, or some other non-programming stunt.
• Some other technique that's eluding me at the moment (fingers crossed...)

Note that these are identical, INTERNAL, helper classes that are necessary for both projects.

You could use the InternalsVisibleTo assembly attribute for friend assemblies that allows an assembly to access the types and members that are marked internal in another assembly.

Usually, it is implemented by using Class Library project, which you need a third project (which is of type Class Library).

Class Library project has output of .dll extension where it can be used by any other .NET projects (written in any languages). To use the dll, add reference to the file, and put

using the_namespace_of_dll

This is the absolute solution

I generally use a separate solution (complete with tests) and add a reference. Then I use ILMerge at the end to not expose a separate DLL (this has worked okay so far for me). The method John Rasch pointed out can be used in conjunction to keep "it" from being exposed, although I generally err on the side of trusting the user/other developer(s).

I avoid copy-'n-paste at [almost] all costs. The SCM approach can work, but doesn't really force an ABI to be developed and isn't well supported in different SCMs. SVN without help is pretty bad at it unless one solution is "the owner"; then the externals can fair so-so.

For anyone visiting this page looking to do the same thing, I found this more in-depth explanation crystal clear:

http://dotnetstep.blogspot.com/2009/01/internalsvisibleto-attribute-usage.html

Add the code to one project, then add it to the other as a link. Then you don't have to worry about "InternalsVisibleTo" - it's just there. The code is the same file for both projects (or as many projects as you like).

or

Don't be afraid to edit XML .csproj files. For instance, this works ...

<Compile Include="$(Codez)\z.Libraries\diff-match-patch\DiffMatchPatch\**\*.cs"
Exclude="NotThisOne.cs;**\NotThisFolderWith\This*.cs">
<Link>Libs\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>

...and will give you all the C# files from the source folder, and subfolders, as linked files in your destination project under a folder called \Libs\.

• $(Codez) is a Windows Environment Variable I use on my PCs.
• I also could have used *.* at the end instead of *.cs.
• This is one of those things Visual Studio might break on you, adding a file into the folder full of wildcard-linked files may break them out to separate entries. Or not. Depends on the wind.