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.
Related
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.
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.
Technology: ASP.NET 4.0, C#, forms/mvc
I am a .NET web designer and I wish to create a modular based website for people, similar to what DNN does (but I want to create my own cut down version).
The idea is that I create a base website that can 'activate' features which the client needs (and has paid for). These features may be used by many clients which require frequent future updates for all clients (so I wish to keep upgrade time down to a minimum).
For example, I upload the base web application using web deploy and it sets up the core database tables/views/SPs in the process.
Then I login into the website as developer and activate the out of the box features that I wish to permit the user to take advantage of.
The only way I can think of currently is via user control, resources etc..
But I need a little of your experience and advice over what the possibilities / dangers are....
e.g. images for an application e.g. blog, that I have activated for a client - how do I reference those images
e.g. Can user controls be dynamically added to a web application (which is pre-compiled unlike a website - it must be a web application since I am using web deploy).
e.g. Modification of web.config to add additional routing (doesn't matter if app has to go down to do this).
The idea is that I can upgrade websites features en-mass, rather than manually enhancing each individual website which given a certain amount of clients would result in an awful amount of time lost.
I do not have access to sharepoint (nor do I intend to).
Any advice on how to automate modularity completely via a front end in asp.net would be superb!
My main problem is how to reference files and resources outside of the websites directory and without using virtual directories (ideally - but open to suggestions).
Thanks,
Dan.
I would suggest that your idea sounds like an ideal scenario for WebParts. There are lots of resources on how to go about building a WebPart management structure from scratch. Then, in terms of your 'bulk update' facility, it would simply be a case of tweaking database entries that are used to configure which web parts a user sees.
I'd be interested to know what you decide to do.
Best
Ian
Try a Multi-Tenancy Architecture as you can find some good info here :
http://codeofrob.com/category/10.aspx
http://weblogs.asp.net/zowens/search.aspx?q=Multi-tenant+ASP.NET+MVC+%E2%80%93&o=Relevance
I am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.
We have a ten-year-old ASP application that we are considering planning an update for. We want to take advantage of the new technologies that ASP.NET has to offer, as well as the opportunity to fix some issues with the existing framework (the existing code-base is highly fragmented, nearly impossible to test, let alone debug, and the entire application appears to have been constructed according to the "Farmhouse Pattern".)
To that end, it seems that the time has come to rebuild this application. But, we are a small business, and we simply don't have the resources to either hire out the rebuild, nor to dedicate our small team of developers solely to the task of rebuilding (we've got other tasks on our plate, and can't concentrate on this one particular task for the length of time it would take to fully reconstruct the application).
What, then, are some useful strategies we can employ to help us convert this app, without having it consume all of our limited resources for the duration of the re-write?
Sounds like an interesting challenge. It's definitely not going to be easy, especially if you can't dedicate any resources to the project full time.
If you have a 10 year old application that is working, I would suggest not going for a complete re-write at all. I would start by sitting down and figuring out what you want your end product to be.
Is it going to be an ASP.NET MVC Web Application, an ASP.NET WebForms App, or something else? Once that decision is made, come up with a loose design for an architecture. If you do things correctly, you can build out bits and pieces of the business logic in .NET and utilize it from your Classic ASP code until you're ready to re-write the UI in .NET as well.
I agree with what Justin said; if you have a working application in place, you'll need a compelling reason (i.e., money) to justify the expense in rewriting the application for a new platform.
Although ASP classic and ASP.NET share a similar-looking syntax and some common coding conventions, they are very very different from each other. If you tried to simply copy-paste classic ASP code into an ASP.NET application, you might be able to get it to work, but you'd be missing out of a lot of the advantages of ASP.NET Web Forms or ASP.NET MVC (and their respective frameworks, of course).
You can, however, extend the functionality of the existing site with .NET code through web services or COM interop. We have a 10+ year old classic ASP web site and I've used both .NET web services (.asmx) and COM-callable .NET DLLs to enhance our existing application. In both cases, I wrote all of my new business logic in the .NET component and provided a chunky interface to work with the existing ASP page. That allowed my .NET code to be very easily testable and still use our existing (huge) investment in our classic ASP site.
The only approach that has worked for me is to carve of areas of functionality in small slices, and rewrite. "Converting" first, then refactoring seemed like a good idea a few times, but in the end just became horrible messes of code written in ASP.NET instead of ASP - and that added no value.
If you have a site that has distinct areas of functionality, carve one off and start with that (I chose "contact us"). Write it the way you think it should be written - that is, assume your new part is fitting into the end design of your well-written app. If you have to add "hacks" to interface with the old system, make sure they are isolated and commented.
When working on an update, think "can I carve of some of the functionality here into it's own bit?" - if so, convert it then update it. I found that if you insist on keeping the NEW app clean and allow yourself to add small hacks to the OLD app for communication, you get the best results.
This does mean you'll have two separate apps (two IIS web apps) for a while, and can make cookie/url and session management a bit hairy, as well as adding one more deployment concern. To combat this, make sure that you minimize state in your web app (always a good idea anyway), and share state through something other than Session.
If you do this a piece at a time, make the pieces small enough, and have a good design up-front, this works well - at least in my experience, it's the way that works best. Note that my experience may not match reality.