Develop Reference

C# Integrating classes from Shared Projects with many projects

I'm splitting an old project up into it's component parts so that the individual components can be used by several other projects.
There are around 4 stages that are split up into components and 3 master projects which will reference these components.
There's a main class (located in the Shared Project, call it Master class for reference) that is consistent throughout that is shared.
I've setup a shared project and added the references, working fine.
The problem comes when trying to pass a variable using Class A (referenced from Project A's version of Master class) to a method in Component A's version of Master Class, I get compatibility issues.
(Along the lines of cannot implicitly convert MasterClassA to MasterClassA)
I know they're identical and I understand that they are essentially a separate instance of Master class, which is why they're not currently compatible.
I've looked into generics/reflection, changing to a Portable Library Class and seem to be going around in circles.
I know reflection is slow so I'd like to avoid it if possible.
Any guidance on best practice and how to resolve the issue?
Here's a crude diagram of the layout.

In case anyone comes across this, this answer resolved the issue for me;
Referencing shared project in several projects of solution
Essentially we create a class library that references the Shared Project, then reference the new project, not the Shared project.

C# MVC Project Architecture for multiple subdomain

I am trying to build a new MVC Project. The thought is I will have a parent domain, and I will be hosting multiple sub products at different sub domains.
[ For Users it will be totally different products.. like: life.insurance.com and general.insurance.com].. and it is also possible that two different teams work on these two child products and they may have different Release Date.
Main thing is, I want to change my Web Project Layer. The Domain Layer, DAL Layer, etc will be common. I was searching for some best Industry Practices in MVC.
Thoughts that I have in Mind:
Create different MVC Areas in Web Project. But what if I want to send product A code to Production but not the Product 2 Code. [How to Resolve this]
Use different Web Projects and change the dll only at Production.
Please suggest. or any New way to handle this scenario?

Under Main Project solution, Create Separate MVC projects for each of the subdomains.

You can create multiple projects for DAL, DomainLayer, Crosscutting, DTOs, UI, Test etc. You can extend it as much as you need and you can find many sample architectures in different complexities. Considering your specific questions, you can route requests using Area as you pointed. In addition, you can implement Areas in different projects which enable you extend your solution without modifying the web project. However; you need to take into consideration that once you add DLL references to your web project, you cannot directly change specific DLLs without rebuilding the whole web project. In order to achive that, you need to resolve your plugin assemblies in runtime. So, you can use Assembly.Load that will help you load specific DLLs anytime you wish.

How to refactor large projects in visual studio

I always run into a problem where my projects in Visual Studio (2008) become huge monstrosities and everything is generally thrown into a Web Application project. I know from checking out some open source stuff that they tend to have multiple projects within a solution, each with their own responsibilities.
Does anyone have any advice for how to refactor this out? What should be in a separate project vs. part of the web project? Can you point me to any reference materials on the subject, or is it just something you become accustomed to with time?

Organize your project cleanly into namespaces. Namespaces should not be too big, not too small. Make each namespace have a public "interface" (i.e. a set of public classes) and don't access internal implementation details of the namespace from other namespaces. Different namespaces usually address different parts of an application, e.g. you'll have namespaces related to UI, business logic, helper functionality, etc. The Framework Design Guidelines have some good suggestions how to design namespaces.
When you feel that your project grows too large, simply identify sets of namespaces that are clearly related to each other and move them to separate projects. Since other namespaces already just use the public interface of the moved namespaces, refactoring the namespaces into new projects is merely a file-move-operation.

Start from the bottom up (your simplest classes that don't depend on anything else besides the Framework) and see if you can isolate the dependencies into functional units. For instance, if you have a bunch of data or business logic classes that reference each other, but never reference any of your UI classes, then you have a candidate for splitting off into another project. If you can't find clear separation points, then you have a design problem and should probably do some refactoring.
I also agree that using namespaces is a good place to start. Even within a project, you can often isolate or minimize dependencies in a way that naturally groups classes together. Putting them in the same folder reinforces this grouping as a functional unit and may really help the poor guy who has to maintain your code in the future. Trust me, I try to think about that poor guy because, on more than one occasion, that poor guy has been me. Twas a small comfort that the person who wrote the code had the same name as me at the time that he wrote it.

Check out the guidance given by the Sharp Architecture project. Its ASP.Net MVC but the same principles apply to ASP.NET and other projects. The guys that put this stuff together are smart I generally use their advice as the default and only stray when I have a good reason.
The basic tiering that they propose is
A core project for your domain objects and interfaces for accessing external services (including persistence).
A data project that depends on core and implements all the interfaces for accessing persistence
An application services project for supporting application-level concerns such as logging or login validation. This only references core.
A web project that holds only views.
A controllers project that holds your bootstrapping code and the code for coordinating your web layer, domain.
In the case of an asp.net app I like to use the mvp pattern which would basically mean the
Web project holds your WebForms and codebehinds which should contain only the minimum amount of code required to redirect to the presenter. You probably also will need to put your bootstrapping code in there. This is due to an ASP.Net limitation and you should NOT reference any of that stuff from your codebehinds.
Controllers project is replaced by a presenters project. The big difference here is that somehow the presenter has to be instantiated by the WebForm rather than the other way around.
You can also try to check out the ASP.NET MVP project.

Where do I put classes when using Web Application project type of Visual Studio .NET instead of Website? (ASP.NET)

I have plenty experience creating ASP.NET Websites in the Visual Studio. But there is an alternative way to do the same thing that is through Web Applications, which have slightly different file structure.
Since I created my first Web Application I couldn't use classes (.cs files) in the App_Code folder anymore, they were not seen by the ASPX and ASHX classes unless were moved to the same file.
It happens that I use the same classes across many files and I don't want to have multiple copies of them. Where do I put those classes? There is any solution without creating another project?

We have been using Web Application project type in VS 2008 for all our projects and put our common classes in AppCode folder instead of App_Code folder. It works absolutely fine, we access our classes across all the pages in the application without any problem at all.

With Web Application Projects you have a lot more freedom. Just create subfolders under your project to hold your classes. For example, you could have a folder named "DAL" to hold the Data Access Layer items.
Optionally, you can create an assembly project and put your classes in there and just reference it from your WAP.
Ultimately the structure is going to boil down to how many classes you will have.

Why do you not want to create another project? This would be the simplest approach as all your classes would be housed in that assembly which you could project-reference in your web application and then have access to everything across the entire project.
I would highly recommend that you consider this approach.

I normally have three projects within a solution. The web app, the web library (base pages etc) and the DAL. This keeps everything clean.

Put them anywhere you want. I tend to keep the little project-specific helper classes and base pages in a /Helpers folder under the web project, but split out DataLayer stuff and general-purpose reusable helpers to their own separate projects.

I use /Shared/Classes for general purpose classes used throughout the site. I like putting the rest of the classes in a Classes folder where they are used such as /blog/Classes/.
-- EDIT--
The answer above was how I stored classes in Web Forms application projects. Now that I am using MVC, I store general purpose classes in /Classes and non-general classes in subfolders under /Classes such as /Classes/Blog. In short, Old_App_Code has been renamed to Classes. This seems like a natural extension to the naming conventions I see Microsoft using in MVC, plus it works with my old Web Forms pages too.

I highly recommend that you put all your classes (domain objects) in a separate project. This way you will be easily able to write test against your business layer (domain objects) and your classes will be portable. Portable means that you can send your DLL to another developer and he/she can easily reuse the classes you developed.

Creating reusable UserControl assemblies with VS2008

Is there a recommended process for creating reusable ASP.NET assemblies that contain UserControls that can be shared across projects in separate solutions?
We have currently have a set of post-compilation steps that run aspnet_compiler.exe on the project, generate the precompiled assemblies using a given name, followed by aspnet_merge.exe to combine each individual control assembly into a single assembly - which is then copied into the bin directory for the project.
Unfortunately, user controls compiled in this manner don't 'play well' with the VS designer - and throw exceptions at design time that make working with pages that host them cumbersome.
Is there a better approach for doing this?

That is the only approach that will put them into a portable stand-alone assembly like that. Sounds like you already know everything referenced here, but this is the best article I know of that discusses the technique:
http://blogs.msdn.com/davidebb/archive/2005/10/30/487160.aspx
What I've always done is just require the ascx to exist, too. The code-behind can be in the portable dll, but still require the ascx. You can help manage duplicates by keeping them all in one place and mapping virtual directories to that location. The advantage of this approach, even though it is low-tech, is that each app if it wants could customize the ascx's look. It could move things around or change the styling, etc, and the code-behind would be none-the-wiser as long as the changes didnt affect which server controls exist.