Develop Reference

ASP.NET MVC - Merge Multiple Small Apps

We have a number of small ASP.NET MVC apps. All are basically a bunch of forms which capture data and store them in a SQL Server database, usually which are then loaded through to our datawarehouse and used for reporting.
We are looking to rewrite all the small applications and apply a level of consistency and good practice to each. All the applications are fairly similar and I think from a user perspective it would be better if they seemed to be part of the same large application so we were considering merging them together in some way as part of the re-write.
Our two currently preferred options seem to be:
Create a separate portal application which will be the users point of entry to the apps. This could have 'tiles' on the homepage, one for each of the apps (which would be registered in this parent app) and could link them through to all. In this scenario all the Apps would remain in different projects and be compiled/deployed independently. This seems to have the advantage of keeping the separate so we can make changes to an app and deploy without affecting the others. I could just pull common code out into a class library? One thing that annoys me about this is that the parent app must basically use hard coded links to link to each app.
I looked into using 'areas' in ASP.NET MVC and have all the small apps as different areas in one big project. This seems kindof cleaner in my head as they are all in one place, however it has the disadvantage of requiring the whole app deployed when any of the individual ones are changed, and I have a feeling we will run into trouble after adding a number of apps in to the mix.
We have a SharePoint installation and someone suggested creating the portal type app in SharePoint... This doesn't sound like the best idea to me but am willing to consider if anyone can point out advantages to this method.
Are there any recommendations on the architecture of this? Has anyone completed similar projects in the past and something worked well/not well?
We have 4 developers and we do not expect the apps to change too much once developed (except to fix potential bugs etc.). We will however plan to add new apps to the solution as time goes on.
Thank you

MVC Areas advantage would be allowing code sharing, by refactoring the repeated redundant parts of each app to use the same infrastructure code (security, logging, data access, etc.)
But it will also mean more conflicts when merging the code initially.
Deployment concerns can be mitigated with a continuous deployment tool (there are many in the market) or if you deploy to an Azure WebApp, then deployment slots can give you a zero down time deployment.

Is it Possible to use Visual Studio/C# to develop for SharePoint 2007 without Deploying DLL to Hive

If a customer does not allow installation of a .dll into their SharePoint 2007 hive (or the GAC), is there any way to create webparts, etc. with Visual Studio that will not require deployment of the .dll(s) into the hive (or the GAC)? If not, is there another way to use Visual Studio and/or C# with the SharePoint namespace functionality in a similar fashion even if not quite in the standard way? This customer isn't going to allow us to install anything on the box beyond the pages and, if not into the GAC or hive, SharePoint-related .dlls developed by us.
Note: there are some specific project details at the end of the post.
Final Summary of Accepted Answer:
No answer was forthcoming with an alternative method of deploying custom SharePoint assemblies (e.g. not GAC and not hive).
It is possible, however, to use C# embedded in a page, and you may reference the SharePoint assembly and use it in the code. (see accepted answer for details)
Many of the things that I had expected would need custom code do not seem to, nor does it seem that in many cases it would even be possible/beneficial to do so.
I have a few basic ideas on how it might work ("magic happens"), but, being firmly in the "don't know what I don't know" quadrant right now, I don't know if it can be done, and I don't know whether any possible alternative route would even gain anything beyond just developing directly in SharePoint Designer sans C#/Visual Studio altogether.
ideas:
Develop with Visual Studio as normal, using WSPBuilder or a stock SharePoint project, but instead of normal deployment, installing the .dll(s) in a non-hive location on the machine, and then somehow including the items as an external resource.
Create a self-hosting web service that somehow can be called serve up components that can be incorporated into the SharePoint site.
Develop separate web pages/web controls in a non-SharePoint web project, then including them somehow into the SharePoint site; or, somehow creating a reference to them in the IIS directories
Develop seperate web pages/web controls in a WebApplication and using the Hostable WebCore to deliver what is needed, and, of course, somehow including the served up pages into SharePoint.
And, my final concern is that even should I figure out the details on the "magic happens" steps, I still would really not have gotten what I want, which is to be able to use the functionality of the SharePoint namespace in a useful way, e.g. connected to the site we are developing, and with sufficient access to do what we need without jumping through too many hoops, either from a developer perspective (e.g. code that's hard to use or maintain), or a bad user experience (e.g. user repeatedly getting login prompts).
(My apologies if the answer is obvious; I'm brand new to SharePoint development, and I'm only experienced with high-level Web development (e.g. fairly simple .ascx/.aspx, and mostly using the designer for pages), so I'm having to get my bearings quickly. When I search for help with the 'obvious' search terms, I get an overwhelming amount of information for normal scenarios, but have not found an answer for this.)
Upon request, here are the details that I can give about the particular project. I currently have information on only a piece of it, and it's a long-term project with a lot of pieces that will build on one another. So, unfortunately, if the solution isn't fairly generic, I will probably have to go the SharePoint Designer route to avoid the risk associated with relying on a method which may not be compatible with pieces that come down the road. Also, I apologize for how generic these are; I am trying to provide a list of capabilities needed as opposed to detailing the actual project.
ability to have individual user site home-pages that allow them to view various bits of information about projects they own and projects they are involved in
ability to have site templates that store wizard-type steps to be followed by users
ability to link the wizard templates to various documents and possibly other things associated with the various steps
ability to store various associated roles and attributes (such as how much time is allowed for a task to be completed) with the items in the templates
ability for a user to use the wizard to create instances of the site items and allow or enforce the assignment of other users based on the template attributes
ability for some roles associated with an item to edit the document and save it back, and to restrict others from editing them
ability for users other than the creator of the project (probably based on a project role assigned by the user) to view all info (timelines, etc.) and edit all documents in the project
ability for the associated users that have roles assigned to mark off when they are complete with their portion of the task
ability to calculate timelines based on info from the attributes for the different items in the project
ability to notify users (via email and site homepage notifications) in roles that have to take action or are marked as needing to received updates on one or more project items
ability to lock down project items from modification once a step has been completed; and possibly to unlock and/or retract steps
ability to automatically create reports and send them to appropriate locations (probably e-mail, but also possibly an administration page on the site, or to another site entirely.)
ability to mark completed projects and archive them in a separate section only viewable by certain windows groups or groups defined on-site
I also know that there is an intent to greatly increase the scope of this project once we complete the first part to the customer's customer's satisfaction. I am trying to find out more information and will post here if/when that is available.
I realize that some of what's there might really have nothing to do with SharePoint in particular, and some of it may not really give enough information to tell you which feature or other it will need. I am happy to clarify anything that doesn't make sense, but I wanted to try to give a little detail as someone else may have a lot better idea of what SharePoint pieces would be necessary or possible to use than I.

If you can at all wing it, you should see if it would be possible for an upgrade from sharepoint 2007 to 2010 to be made, because many of the problems you are describing are made a whole lot easier to solve in 2010.
Something that would really help me develop a more thorough answer is a very brief description of what functionality you are attempting to achieve.
OK, Thanks for the update.
I will try my best to address all the points of the project.
Your first point is easily available using something called a Mysite.
For all the points where you are discussing wizard templates that can store documents and associated data, you might want to look into Microsoft Infopath, no guarantee that it'll be a perfect match, but take a look and decide.
The great part about infopath is that when you combine it with Sharepoint Workflows, you can set rules for doing things, and different views, this will allow you to assign roles associated with editing privileges and such on documents.
Again, since infopath has the ability to easily submit to a sharepoint list or document library, any data based calculations are as easy as selecting which data you want, and what you want to do with it.
For the notifications, sharepoint workflows in microsoft sharepoint designer allow easy email creation.
As far as your last bullet point goes, this is another workflow, and the ability to make sites viewable to only certain groups is a basic functionality of sharepoint.
These are all available in SP 2007, but honestly, it would be financially more responsible as far as the difficulty and length of the project to use SP 2010. Also, the transition process is smooth and you don't really lose anything, just gain. From what you've said though, this might not be possible, which is a shame, but good luck either way!
This part should help you out with the C# pages, here is a basic hello world page.
<%# Page Language="C#" %>
<script runat="server">
public void Page_Load(object sender, EventArgs e){
Response.Write("<h1>Hello World!</h1>");
}
</script>
I normally code this in sharepoint designer. Also, say if you need to work with Microsoft.SharePoint.dll, provided on the server, you could add this line: <%# Import Namespace="Microsoft.Sharepoint" %>, since it is a page on the server, you don't need to specifically link it in any way, just that one little line after the page language declaration. Hope this clears everything up!

An option would be to deploy code to the BIN directory instead of the GAC.
The BIN directory runs with minimal trust. However, some things can't be deployed here (like event receivers).
See also, How to deploy a SharePoint web part to bin.

We have a solution which employs IronPython scripts. There's a IronPython web console, generic IronPython event receiver, page, workflow, timerjob, library of scripts which can also be edited through web interface, and a list with necessary configurations. I'm hoping to opensource the core of it at some point, but the full version can do a lot more.
The point is we don't need to do redeploys for every single little thing that needs to be added or changed for each particular customer. Particularly with workflows - we can do small changes without breaking everything that's currently running.

Providing multi language support in web application

I am developing a new web application from scratch. I need to provide multi-language support in my website. Which enable users from different regions of the world to see each web page in their own language.
Since, i am new to this field so i don't know how to achieve this. One possible way is to make each single page multiple times for each different language :(
But i am not will to do so, because it increases the development and maintenance time.
Secondly, what to do with the database, do i need to make some considerations while designing database?
I will develop this site using ASP.Net with C# and use MS SQL server as backend database

You certainly don't want to create separate pages for each language.
ASP.NET is quite well geared towards multiple-languages within one page - with the use of resource files:
An effective way to create localized
Web pages is to use resources for your
page's text and controls based on the
user's language and culture. By using
properties placed in resource objects,
ASP.NET can select the correct
property at run time according to the
user's language and culture.

Using resource files can be a bit of a nightmare for large sites, you may want to check this database resource provider out, although you would have to edit resources from the database as the visual studio resource editor only works with file-based resources.
Implementing a database resource provider

ASP.NET vs SharePoint - which one is better for web developers?

I have less information about share point (only basic info). Microsoft released SharePoint for web developers. Microsoft also said SharePoint has compatibility with other .NET technologies like Workflow Foundation, WCF, etc and it's easy way to develop web sites and web apps.
Also as I know ASP.NET has compatibility with .NET technologies and C#. And it easy for every one whom at least work with C# or VB.NET.
So with these advantages of SharePoint:
Why we must use asp.net instead SharePoint?
Why Microsoft develops ASP.NET (new version 4)?
What's major reason to chose one of these?
Is really developing base-on share-point faster and easier than asp.net?

SharePoint is an Application that sits on top of ASP.net (3.5 SP1 in the current SharePoint 2010 - No ASP.net 4.0 will be possible). They do override a lot of ASP.net built-in functionality (they have their own .aspx Parser and Virtual Path Provider for example).
With ASP.net you have a very well documented, battle-hardened, mature and stable platform with a good API.
With SharePoint you gain a poorly documented, bug-ridden, very limited application that handles a lot of features that you would have to code yourself (e.g., User Profile Management, Document Organization and Versioning and Social Features like Commenting and Tagging), although for the most point SharePoint handles them really poorly and does not allow you to override them, which means that you spend a lot of time rewriting them anyway and trying to integrate them back.
Basically my advice as a SharePoint developer since 2006: Use it when you absolutely have to, avoid it whenever you can and stay with just ASP.net.
SharePoint is good as a simple document management and very light social system. You can quickly customize smaller parts of it and add a lot of value to your company. But in the moment you need something that even only slightly different from what Microsoft envisions, you hit a wall that you can't pass. It's great for what it does, nothing more, nothing less.

I am a Sharepoint Developer... And let me say that I wish it was just ASP.NET! That would be great... It brings with it it's own paradigms which are pretty complicated.
ASP.NET and Sharepoint are 2 'different' technologies. Sharepoint is mostly built with ASP.NET, and delivers ASP.NET pages to a user.
You can use either VB.NET or C# with Sharepoint.
In my opinion, Sharepoint development is only quicker if you are planning on using it's in-built lists, user management etc. Though these do take time to learn. The cool thing about sharepoint is that you can develop web parts, and re-use these web parts on multiple pages throughout the installation.
Microsoft continues to develop both ASP.NET and sharepoint because they are two different beasts, with ASP.NET pages being deliverable through Sharepoint.
As to which is best for you, you haee to make that call. Do you need Sharepoint? Or would a pre-built CMS such as DotNetNuke be better? Or even creating your own site with Windows credentials management so you can use SSO (Single Sign On).
It really depends on what you want to get out of your install. Sharepoint is expensive, and developers for Sharepoint are also expensive because of the specialist knowledge.
As a developer... (I hope my boss isn't watching!!) I much prefer to build things from scratch than to use SP, but that's my job...

Don't use sharepoint unless you need it, check this article:
Challenges when using SharePoint compared to ASP.NET

If you just want to create a website, go for ASP.net.
However, if your company has a SharePoint installation and you want to integrate with that, you should go for SharePoint.
SharePoint is build on ASP.net, but has many extensions that allow data to be shared throughout the company.
However, if you are just building a website and don't need all that, ASP.net is the way to go.

I'll try to answer point by point:
SharePoint isn't a replacement for ASP.NET. It's an extension of the ASP.NET platform that simplifies the implementation of several common use cases that are mostly relevant to enterprise websites: document management, knowledge retention, collaboration etc... SharePoint relates to ASP.NET in a similar way that Wordpress relates to PHP: it's a specialized extension rather than an alternative.
Same explanation as in (1).
Use SP if the things you need to develop are in the scope of what SP provides, which is mostly enterprise solutions of one sort or another. Here's a good summary of what SP can do.
Again, it would be faster and easier if you're trying to develop the things that SharePoint is meant for. Also, SP isn't so well-documented, so if you're not familiar with it, you might have a slow start.

SP is a very powerful platform, however, it does seem to bring complexities to the table that otherwise may not be there with simple ASP.net. Plus when you move "OOTB" with SP it becomes a bit challenging with RTM, etc. I live in blogs with "weird" things that happen. I am not a full blown SP developer but have been working with it for over 7 years and well, I find building solutions that will work within SP, but not necessarily built withIN SP generally are going to be easier to maintain and controllable. Just my opinion!

I would compare all for you and its up to you to decide.
ASP.NET >> Its a programming language by Microsoft which means you would need Windows Server + IIS + Database server like SQL Server + some Anti Virus on the server.
Say now you need some more PC for your servers and so your costs go up all the time you need a new server
Sharepoint Server are again from Microsoft and so everything above applies.

ASP.NET: Creating versions of the same website

My new assignment at work is to create a second version of our existing web application. Currently, our application supports only full time brokers, but now we our launching a second site specifically for part time brokers.
The new site will be almost identical to our existing site with the following exceptions:
It will have it's own branding.
A couple of the user controls used for displaying information will be different (but none of the pages will be different).
Our existing users should not have access to the new site and vice versa.
It needs to be easy to test both versions of the website from within Visual Studio easily.
We want to reuse as much our existing code as possible.
I have 2 weeks to do this.
I'm hoping that this is a common scenario and someone out there has some advice for how to accomplish this.

I really, really don't recommend branching projects or other routes which involve copying what is essentially identical code with the exception of branding and authorization. It will certainly be easier in the short run but, as you said, will become a nightmare very quickly trying to maintain almost-identical code bases.
Your pages can make the decision on what controls to show based who is logged in or even set globally to indicate this is the part-time broker version of the application. You could have a set of views and light logic to handle part time vs. full time brokers. Since the sites are deployed separately, a config setting would be straightforward. If you have other versions of the same site, you may have to give this some thought to ensure it would scale with your other variations.
I would even use the same database as long as you can separate the data appropriate using claims-based (preferred) or role-based authorization or similar.
All this said, there does not seem to be any great reason why you'd want to deviate from using the same code base.

I would create a branch of your code and then work against that. This is of course assuming that you are using version control. You are aren't you?

My first thought would be to
copy the entire source code to another IIS website
script the database over to another database (fresh start for new website)
make necessary adjustments to usercontrols and branding
roll out the new site (as Beta)
In Visual Studio, you can create a new project inside the same solution so that you have access to both projects at the same time.
If you're using Version Control... create a branch, and start customizing from there.
what this will do for you is give definitive separation between the two sites... no users have access across sites, all future customizations will be on a per-site basis, etc.

While I really like the idea CaptainTom posted another solution would be to break off the display layer of your application from the rest of the logic and create a new project that implements the new user experience while sharing the rest of the code
i.e. a FillTimeBrokers project and a PartTimeBrokers project with both implementing their logic from a common Brokers project.