We Keep Coding

Making a Saas MVC App...need customer specific views, resource files, and logic

I am building a hosted business SaaS application using MVC 4/C# 4. I'd need to have customer specific resource files, css, views, and business logic that leverage a base code layer as much as possible. How would each of these (resource files, css, views, logic) need to be structured to accomplish this?
I realize this is probably a very in depth answer...but I have no idea where to start or what to search for to begin to research this. Any pointers so I can research further?
Here are my initial thoughts on each:
Views
Use a Switch statement based on user to return different views.
CSS
Use switch statement in view to specify which css to load
Resource Files
I'm not using them now but need to implement, so not sure exactly how they work. From what I've seen you can specify a resource file at the class MetaData level, which is a compile time thing. Not sure how you would change this at the user level. I can see here, how to change it based on culture...but not by a user profile attribute (like the company they belong to).
This looks like a start...will review more.
Business Logic
In my services layer, I could implement switch statements...but that seems messy. Is there a way to create a new classes that override the base classes but only for certain users? Or putting these in a separate project/dll and only using that dll reference for a certain user?
I used to work on the IBM iSeries, and they had the concept of a library path that could be set by user at login. You'd have a custom code path that overrode the base code path libraries. Is there anything similar in MVC?
Data Localization
In my database, I have a table for Orders and another for OrderStatuses, which may be displayed in a drop down for the user to select a status. These statuses may be 'Open' and 'Closed'. But another customer may want that in Spanish...How would you handle this?
Any other considerations I am missing?

Use switch statement
Any time someone is writing object-oriented code and mentions a switch statement to control variable requirements, alarm lights begin to flash.
When you have similar but different requirements, polymorphism is your friend.
Without knowing full details of your requirements it is difficult to provide a specific answer, but consider using the factory pattern / dependency injection to provide objects appropriate to a specific user (or more probably, to the company associated with a specific user).
UI Layer
Generally speaking you could use a factory to return controller instances, based on a common subclass, that implement requirements for a specific user/customer and return views appropriate to that user.
I'm not well enough versed in the specifics of wiring routes in ASP.Net MVC to suggest how specifically to set that up, but it feels like the right approach. Perhaps another poster can shed more light.
Business Logic
This is a classic use of polymorphism, when requirements vary significantly. Alternatives to per-customer classes include configuration-driven behavior and rules engines. The best choice depends on your specific sitation.
Data Localization
Things like order status in the DB should not be bound to a text like 'Open'. They should be bound to a binary representation (e.g. an INT). Leave it to the View to translate that meaning into something specific to the user's language.

In a SaaS application we have developed we have clients who have their own private domains so being able to support something like that was a must. We had to be able to support:
www.mycompany.com/u/clientname
clientname.mycompany.com
www.clientname.com
On of the things we considered was how we could use a single deployment/code base to handle all of these clients. What we ended up with was a Base system that could be extended through the use of "plugins" which are basically class libraries named "APP.Clients.{ClientName}".
We wrote a custom ViewEngine that allows us to make use of these plugins to load Views, Controllers and even Controller Actions from the clients custom plugin to over-ride the base site.
What we ended up with is similar to what people call "portable areas" or basically external views and controllers in an Assembly.
Clients can share a common "network" database or they can be rolled off in to their own database. Most all of the config comes from reading the current URL and having logic that can determine which "client" it is and loading their settings and processing their customization.
Being able to load the client views required adding in additional search locations for Master Pages, Views and Partial Views (why we have a custom ViewEngine).
There is no simple answer and what works for one SaaS project may not work exactly the same for another. Your architecture will likely be similar but your business needs will dictate where your project takes you!

How to turn on/off code modules?

I am trying to run multiple sites using single code base and code base consist of the following module (i.e. classes)
User module
Q & A module
Faq module
and each class works on MVC pattern i.e. it consist of
Entity class
Helper class (i.e. static class)
View (i.e. pages and controls)
and let say I have 2 sites site1.com and site2.com. And I am trying to achieve following functionality
site1.com can have User, Q & A and Faq module up and running
site2.com can have User and Q & A module live while Faq module is switched off but it can be turned-on if needed, so my query here is what is the best way to achieve such functionality
do I introduce a flag bit that I check on every page and control belonging to that module? It's more like CMS where you can turn on/off different features. I am trying to get my head around it, please provide me with an example or point out if I am taking the wrong approach.

You might want to look at Portable areas. You could design the code base so that each module is an area and then deploy them into the sites were they are needed.

After looking to some example and an extensive research I come to a conclusion that it depends upon 2 scenarios:
Scenario 1:
If in a case where there is only ten possible modules which are written once and require the whole update of the entire application if they need to be updated, then you can easily use checks which will propagate through the models and be used by the views to adjust the user interface (for example by showing or not the appropriate links in the web application menu).
Scenario 2:
If, instead, there is a case of many modules developed by many developers and it is unacceptable to require the update of the whole web application in order to update any of such modules, then look for plugins model, like for example the one used in FogBugz.
For making choice, consider following elements sorted by importance:
Maintainability: is it acceptable to modify the common code of the web application in order to change any of the modules?
Dependencies: are some modules dependent of others?
Performance: since we don't know the exact context, it's difficult to try to predict the impact of each solution. Maybe there will be
none, if you use heavy, cleverly designed caching.
Overall architecture: if there are reasons to do something monolithic (because of the interdependencies), the first solution
seems more appropriate; this is not the case if every module is
strictly separated from others.

Tips/Resources on Structuring Shared Code Libraries in C#/WPF?

I've written a simple desktop application with C#/WPF and I'm now looking to create another, larger application which will share much of the functionality. I'm thinking that I should create three separate projects: one containing the shared code, and one each for the two apps.
My problem is that I'm not entirely familiar with .NET/WPF so I don't know if there are some best practices for this sort of thing. Can anyone offer some good sources of information, example projects or just some brief advice?
Edit: To put a little more detail on the scenario, the first application is a specialised editor and the second application is taking this file editor and wrapping a project model around it to create a sort of basic IDE.

Honestly it depends on what level the code you intend to share is. For instance, it's entirely plausable to put all of your business logic code into one project/class library and maintain it independantly, but mixing biz logic with WPF custom controls should be STRONGLY discouraged. Think about the layers of abstraction you are modularizing, and the dependancy heiarchy you are introducing and refactor accordingly.
Edit:
In response to your above changes I suggest the following: The logic and DAL associated with the above should be pushed into a project as seperate namespaces. The visual elements (the view, viewmodel) should most likely be moved into a seperate project and namespace set as well. Once you can merge these together and launch them from an exe that contains a host window and a UserControl for the rest of your hosted visual content, you can then probably move forward with integration into your larger IDE project. The key here is:
Visual Layer and View Logic -> Editor.Visual.dll
Biz Logic & Data Access -> Editor.Core.dll
I hope this helps.

How to restructure ASP.NET application

I have a sample ASP.NET application. The appliaction was developed as POC and not following any design and architectural standards.
Now I want to restructure the application. I can see some of the business logic and controls can be reused in future, such as login control.
I have two options for restructuring
I create a Utility DLL that will contain all such resusable code and another DLL that will contain all controls that can be reused.
I will create a separeate DLL for each type which can be reused e.g. Login control.
Which option is more better. Although I feel option 1 is good, but I need suggestion from experts.

I have no idea why you would want to keep a separate assembly per type. Don't do that.
Keep related functionality together in a single assembly. Look at how the .NET Framework is organized for examples. Note how, if you're not doing data access, you don't need to reference System.Data.dll.

There are multiple ways to build an architecture. For instance you can create horizontal layers which put all GUI logic, business logic and data logic into separate layers. This is only from logical perspective. Where to put the layers is another question. From OO perspective you put them in at least different classes. You can decide to put them in different name spaces, different project/assemblies.
Just start slowly and refactor the most obvious parts. You can start putting the classes together in a part of the project (folder). Then change namespaces. Then put them in seperate project. Small actions will give you the chance to further consider your options. Each improvement is one.
So my advice is to first arrange classes and namespaces within the current project and so shape the logical parts. Maybe you need to add some interfaces here and there as well to separate the layers.

I would go for a single assembly for your controls. You might create a new assembly for controls which you probably won't use soon or are very special.
I would categorize the business logic and make an assembly for each category.

Is MEF an all-or-nothing affair?

I've had a few questions about MEF recently, but here's the big one -- is it really all-or-nothing, as it appears to be?
My basic application structure is simply an app, several shared libraries that are intended to be singletons, and several different plugins (which may implement different interfaces). The app loads the plugins, and both the app and all plugins need to access the shared libraries.
My first go at MEF was fairly successful, although I made some stupid mistakes along the way because I was trying so many different things, I just got confused at times. But in the end, last night I got my smallish test app running with MEF, some shared libraries, and one plugin.
Now I'm moving onto the target app, which I already described. And it's the multiple plugins part that has be a bit worried.
My existing application already supports multiple plugins with different interfaces by using Reflection. I need to be able to uniquely identify each plugin so that the user can select one and get the expected behavior exposed by that plugin. The problem is that I don't know how to do this yet... but that's the topic of a different question.
Ideally, I'd be able to take my existing plugin loader and use it as-is, while relying on MEF to do the shared library resolution. The problem is, I can't seem to get MEF to load them (i.e. I get a CompositionException when calling ComposeParts()) unless I also use MEF to load the plugin. And if I do this, well... then I need to know how to keep track of them as they get loaded so the user can select one from a list of plugins.
What have your experiences been with trying to mix and match these approaches?

MEF is designed to let you easily load plugin assemblies. If you have control over the plugins (by which I mean that you can add MEF export attributes) then there is no need to keep your own plugin loader which uses reflection. MEF does all that for you.
That being said, "mixing and matching" MEF with other technologies is certainly possible. It sounds like your problem is that if you use your own plugin loader, you don't add those plug-ins to the MEF container. As a result, you get a CompositionException for parts which try to import the selected plug-in.
To add a plugin that you loaded with your own code to the MEF container, you can use the ComposeExportedValue like this:
container.ComposeExportedValue<IPlugin>(selectedPlugin);
edit: I see what you mean now by "all or nothing". Your problem is that in order to be able to import parts with MEF, you also need to construct the object with MEF. This problem then cascades to the object which normally created that object, etc. all the way to the application root.
To avoid this "all or nothing" effect, you can compromise by exposing the MEF container as a global variable (i.e. static field). That way, classes can access the MEF container and pull exports from it, e.g. by calling Program.Container.GetExportedValue<MyDependency>() in the constructor.
edit2: If you have an object that was not constructed by MEF, then there are two ways to add it to the container.
The first is to call container.ComposeExportedValue<IMyContractType>(myObject);.
The second is to return the object in a property getter, and then mark the property itself with an [Export(typeof(SomeType))] attribute.