Develop Reference

ASP.NET Core - Best way to reduce dependencies in business services

It's a web application running ASP.NET Core MVC 2.1 that started as an ASP.NET MVC 3 application and has been growing for 5 years.
I have defined services for different business processes but at some point, many of those services depend on each other. The end result is services with many dependencies and some circular references.
For example, service A performs an action and then it has trigger another action in service B. And then end result has to be sent back to the user. This is a simplification, of course.
In some cases, I'm using Azure Service Bus to decouple the processes. That way, service A performs an action and then queues an action that triggers a process in service B. Then service B is gonna send an HTTP request to the web application to notify the users. This approach worked out well but I'm not sure if I should apply it system-wide. It adds complexity for sure, as debugging is not that simple.
I know someone will say "use Microservices" but that's a big change and for now I need to have one datbase for all the processes.
I found the request-response pattern applied to Azure Service Bus to be really useful but I couldn't find any code examples. Documentation is here: https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-sessions#request-response-pattern
Any recommendations are welcomed :)

I think that's a very complex problem you have encountered and to say there is an obvious solution would be wrong.
Recently I was working for the company project that had an intention to escape, such called Death Star Architecture, which is somewhat close to the problem you have. To escape coupling between projects/services, the company decided to move to expansive solutions based on Azure Microservices (Logic apps, Data Factories, Azure Functions, etc.).
Although it's worth mentioning that the solution solved the issues with couplings because with Azure Microservices, you can easily switch between solutions without the need to worry about dependencies.
There are quite a lot of articles about the good and bad sides of the microservices, and you should examine all the pros and cons before moving forward with them. Also, check the business needs, are there available time and resources for that or not.
One other thing that I can suggest you look at is the reactive programming approach.
Also, you can look at this thread. There are a couple of good suggestions, worth mentioning.

Advice on new project: additional functionality into existing ASP.NET app

Looking for suggestions regarding an upcoming project that I am involved in which revolves around adding certain functionality to an existing ASP.NET application running on IIS 6.0 programmed in VB.NET.
To aid in future development the client wants the additional functionality to be as future proof as possible. Ideally I have said that I would like to push for a solution using ASP.NET MVC3, running off IIs 7.5 and .NET 4, written in C#. This solution would act as a seamless addition to the current web-portal appearing probably just as an extra tabbed page.
But they will be completely separate web-apps. Which is crucial.
The main problems I can foresee are firstly sharing session particulars between the asp.net web app and the new application. Particularly with regard to maintaining session state (and not having IIS timing out on one of the apps). Also, conjoining the two "apps" appears problematic in my head, although this may be far simpler than I fear.
I'm asking for suggestions for these two problems if anyone has any ideas please say!
So far I've come up with the following solutions be they terrible or not:
1) Embed the new functionality into the existing codebase (not a great option). This would mean losing any potential future upgrade-ability and also means not following better OO conventions by utilising the MVC framework.
2) Using an iFrame to link to the razor pages of a seperate MVC3 app (the one I'm favouring currently). Allows uses of all new technologies, however downside is sharing session data. Either through iFrame "attributes" (is this possible?) through persisting a session state to a db? (slow?) or even some kind of web service interaction between the applications to push/pull user/session data?
Any advice/suggestions greatly appreciated!

I agree with you that C# and MVC is the "way to go", but unfortunately mixing two applications together is going to give you a whole bunch of headaches, not least the different session IDs. You'd probably have to have a shared database table to map them together and, as you can probably imagine already this reeks of "Band-aid".
What are the ramifications in rebuilding what is existing, in to C#? Perhaps you could suggest a complete upgrade. The client themselves seem to extol the virtues of future-proofing and therefore this would be the way to go. And no, I wouldn't promote the use of a "code-converter", but it really shouldn't be that difficult.
The next thing to consider, I guess, is "future-proof". Is the client worried that VB.NET is going to disappear any-time soon or that it cannot handle anything in the future? I find that a very unlikely scenario, honestly.
I think I've waffled on a bit, but essentially combining two applications, one with old and one with new functionality will cause a headaches. This could be solved by migrating the old site to C#/MVC, and then adding the extra functionality. True, this may seem like a large commitment today - but further on down the road, it will pay dividends.

If the current site can be upgrade to .NET 4.0 there's no reason why you wouldn't extend the existing application.
There's nothing to stop you mixing MVC and web forms (indeed there are several articles on how to do just this). There's nothing to stop you mixing VB.NET and C# (or, so far as I'm aware, to stop you doing MVC in VB.NET).
You'd have to work very hard to convince me of the merits of using iFrames. Very hard. You might be able to persuade me of the merits of running two applications side by side - with the functionality split by folder - but to be honest I'd be much happier upgrading the existing site and then building from there.

What are some useful strategies for converting a Classic ASP application to ASP.NET

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.

Choosing CMS vs Portal vs MVC+Components?

I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.

With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.

Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.

I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.

I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.

The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!

Expanding an existing ASP.NET 1.1 application using ASP.NET MVC

Currently I'm working with a big, old and extremely poorly written ASP.NET 1.1 application and the continuous maintenance is becoming quite a problem. Basically it's reaching breaking point and I'm reluctant to expand it any more than I have to as demanded by the business. Based on my experience creating other projects from scratch it would really suit an ASP.NET MVC based solution. Oh how I wish the world were that simple...
The fact is that I just cannot justify re-writing it from scratch and the business cannot afford it. The ideal solution would be to start writing an MVC-based application alongside it and begin a slow migration as new requirements arise.
I've read posts which state that this is entirely possible, but in my experiments I've not found it so easy. The current application contains several large data access and business logic layers shared by other applications that the company produces. These are also written in 1.1 and will not compile in 2.0 (and would destroy the other projects if I tried!) so I cannot upgrade them. Since I can't do that I'm stuck with an application that cannot even be opened in a .NET 3.5 capable visual studio. The new MVC app would also have to make use of these layers.
I am entirely open to suggestions. I'm desperate to find a solution that I can quickly demonstrate would allow me to improve the product immensely without taking too much time or affecting the rest of the business.

You could write a WCF service on top of the existing business layer and have your new app talk to that service instead of referencing the business layer directly.

You need to divide to conquer. Analyse the current app and its layers and see if you find a way to divide each significant piece of functionality into a discrete area with as few changes as possible.
Then make each area a unique service using the old technology.
Then you can rewrite each service slowly as you can fit it in and not affect the whole.
Otherwise you are going to have to come up with a convincing business case for your managers so that they allocate you the time to do the job properly. Sometimes our job is political as well as technical.