So on the current system (running off of the .net 3.5 framework) the way it was made was there is a project for the main intranet site. This page uses a dll to load the menu & layout. Then there are a bunch of separate applications (different solutions) that use this same dll to load the site structure and then get deployed as a new iis site. The menu has links to each of these applications and essentially it creates one large intranet site.
The idea is to recreate the intranet which I have been tasked with. I will be using .net core 2.1 and a mvvm (or mvc) structure. So my question is what is the best way to go about this? I am not totally convinced that the current system uses the best approach and I kinda want to get out of the dll hell that the current system uses (there are lots of dlls not just for the layout). As for the layout and its re-usability what is the best approach for this? Should there be separate solutions for each internal project and how would they reuse the site layout if so? Or should it be one HUGE solution with multiple projects? Or what other approaches could be recommended?
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.
I was looking through my companies web application that was developed in .NET 2.0.
On deployment they have nested web application created under "default web site" as in the structure below
Default Web Site
My Root Application
Sub Application 1
Sub Application 2
Sub Application 3
Every application is a .cs project. Many of the sub applications are even just having a single web service(approx. 15-20 web methods) and nothing more.
As the guys who developed this project are not around I was wondering
Q1. what was the reason to take this approach? Was there some limitation on IIS and .NET 2.0 that made them have this structure.
Q2. If I wanted to merge all of them into one single web application. Is it recommended?
Q3. What are the advantages and disadvantages of such web application nesting? when to nest web app and when not to?
I am sorry If this post is appears in the wrong section of stack overflow. If so please guide me in posting it in the right section.
Thanks in advance for all the help and suggestions.
The question is quite broad, without knowing, what are those sub-applications, how, or if, they communicate with each other, and so on. But splitting things apart is usually a good practice. In your particular case: the sub-applications can be better scaled, when you run them on several machines. You get even better maintenance, as if you have to fix something, you deal then with some discrete part of your big application. The architecture should be much better, as when it was possible to split the applications into several sub-application, it means, they are loosely coupled.
In our web applications, we always have usually 3 Web-Projects: API, Web, CMS. I'm not counting here other Business Logic Layers, DAL, etc. So now, we can run them as separate instances, as you have, but we can also run them as one application, we must just specify the routings: API myapp.example/api/**, CMS: myapp.example/cms/** and Web: myapp.example/**.
I currently have an asp.net console application which simply retrieves a lot of data via an API from a remote server and, using Entity Framework, saves it into an SQL database. The application takes 3-4 days to run and I run it manually once a month or so.
The project is separated into a Models class, and a Repository class as well as the application itself.
I need to now build an ASP.NET MVC web application which allows users to view the data that has been retrieved and am looking for advice on how best to structure this.
Do I create a new ASP.NET MVC project in my solution and set that as the start up application, referencing the same Models and Repository classes? If so, how do I then run my console app? Or is it best to keep these as separate solutions, just referencing the same database?
Is there a better way of doing this as well? (ie, is there some way the console application can be rebuilt as being part of the front end and use queues or workers to fetch the data regularly?)
Thanks for your help,
Robbie.
Same solution. Different projects. By being in the same solution you gain the easy ability to reference shared components. I would actually recommend breaking out your entities, repositories, etc. into a third project, a class library, that then both your console app and MVC app will reference.
If you don't put everything in the same solution, then you're either stuck in DLL hell, where you have to build your project and manually copy the DLL into the other project, add the reference, and then keep everything up to date when you make changes in that DLL. The more projects that get involved, the greater the entropy and greater the likelihood that your projects all end up running on different versions of the DLL.
Another option is to create a Nuget package containing the shared components, host it in your own private repo, and then add it to each project that needs it. However, while it's pretty easy to set all this up, it's not 100% frictionless, and you will have to remember to repackage and republish the Nuget whenever you make changes, and then individually update the package in each referencing project.
Long and short, same solution is always the best way to go unless there's a very good reason not to. It's the only "it just works" approach.
Personally I would keep these as separate projects and separate solutions that just reference the same database, but move code that can be shared by both solutions into a separate class library.
The way your web application will present your modeled the data will most likely be very different to how your console application will use it; so using the same models and repositories will most likely further couple your web application to your console application.
This is very similar to the way micro services work, where the micro service acts and grows independent of its consumers (in this instance, your web application) and only communicate via a clearly defined API.
I am working on c# desktop windows form application using some 3rd/.net libraries and all forms are not WPF and no MVC.
I searched about this and I have some questions.
I'm expecting to change the whole gui code to wpf/XAML/ html forms.
I have two options now using asp or silverlight.
If I converted the project to asp/silverlight can I use the existing 3rd/.net libraries and I think I won't be able to get source code to recompile it?
knowing that the application contains tons lines of code and 6 projects in one solution.
what do you recommend for less effort?
and I can't use gizmox because its commercial license
If you are moving from a WinForms to a Web Server based architecture, I would definitely recommend the MVC route. Silverlight as a technology is a dead end and in addition would not allow you to reuse .net code without recompilation. Using MVC allows you to re-use your existing code, for good or for ill, in the server tier without recompilation. Even if you did use the Silverlight technology you could wrapper your existing libraries in a WCF service tier on the server and have Silverlight call it as web service.
However; the move to a web based architecture will require you to re-write a lot of your code (almost all the UX code will need to be scrapped) and this raises the question of what you are trying to achieve by moving to a web based architecture; so you need to consider both the costs and effort as being substantial - there are no quick ways to move from WinForms to Web, but depending on your business requirements you might consider using ClickOnce or XBAP to distribute your existing Windows application via a browser.
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