I am currently starting the development of a new website using ASP.Net Webforms. To give this project a proper start I am investigating a visual studio solution setup for the application, where I want my application to consist of easily recognizable components that are equal in size (lines of code).
Since the project is hasn’t actually started yet I have structured the solution in a standard three tier setup (data, business logic and presentation). This setup is fine at the start of the project but as the project grows the three tiers will soon start to become big and navigating and finding code will become harder which will hurt maintainability and overall feel of quality.
So during the project I want to convert to a new setup where I form functional components that each has their own three tier setup. For example: the website has a shopping cart and options to create and manage a user account. There should also be component for stull used across multiple components, which I will call common for this example. That would lead to the following setup:
The common files:
Project.Common.Data
Project.Common.Business
Project.Common.Presentations
The shopping cart:
Project.Shoppingcart.Data
Project.Shoppingcart.Business
Project.Shoppingcart.Presentations
The account management:
Project.Account.Data
Project.Account.Business
Project.Account.Presentations
The website:
Project.Website.Data
Project.Website.Business
Project.Website.Presentations
The sample above has three components that each contains three projects. Each component has one web application project that contains web files (pages, controls, front-end code). All my previous .Net project all had a simple web application project, so this setup is a new experience for me.
I still want the solution to feel as one application, being able to debug the website and the components with ease. To achieve this I assume the “Project.Web.Presentation” web application project should be the main web application project. I am currently investigating if it is possible to setup a solution this way, I have tried several approaches but none have worked well so far:
Running all the web application project separately, this worked fine but I have to run all the application separately and I cannot run them under the same port which is terrible when debugging.
Adding files from other presentation projects as links to the “Project.Web.Presentation” project and set that project as startup project. This doesn’t work as the files aren’t present at debug time, seems to work fine when building a deployment package. I do not want to copy the files since I have to somehow prevent those duplicate files from ending up in version control.
So far I haven’t found a good way to work with setup I have in mind. I am open to suggestions, thanks in advance for the tips!
I'm working on something similar and decided to use NuGet to push out all the common parts:
Multi-Project Nuget Issues
Updating Files in Existing Nuget Package
Visual Studio Multi-Project Solution Options
The only other way to do this involves nested master pages and post build scripts - messy.
Related
Multiple Asp.Net Framework 4.6.2 MVC/Razor projects within a single solution.
They use Areas, and each project will implement one or more Areas, distinct from the other.
One project acts as the "primary", and includes the global.asax.
The "subordinate" apps can know about the "primary", but not vice versa.
Is it possible to deploy these to the same web site? (on-prem VM).
There would be some collisions, such as the _Layout.cshtml.
Some how I'd have to be able to setup dependency injections for the classes in the "subordinate" project assembly.
Thanks
-John
I don't think this is possible easily, because so much of an MVC site is pre-compiled into DLLs, and yet some of it (e.g. view files) must be actually physically deployed outside the DLL. You are likely to run into conflicts or confusion I think. It's certainly not a reliable, definable process that you could count on in production.
Here are some alternative suggestions to solve the underlying problem, based on what you described in the comments. These are just ideas, some of which I've done or seen done, and might not suit you, but any of them should be a lot easier to manage than trying to bodge the deployment process:
1) Try building the areas in separate projects as you do now, but without all the generic MVC stuff that surrounds it. I.e. Do it as if they were libraries only containing the files specific to their functionality. Then you can package them up as Nuget packages. When they're ready, install the packages into the "main" site to create the combined solution. That way you won't run into conflicts of layout pages etc. If one of the sub-projects changes, then the main site can just upgrade the NuGet package. You can create private NuGet feeds either via Visual Studio Online (if you have a subscription) or on the simplest level via a shared network folder. I think other online vendors offer private feeds as well. We've done that quite successfully to apply some default styles, scripts, layouts etc to all our various MVC apps.
2) Re-architect your solution as a series of separate apps (that's the bit you've already got), but with a central service that provides federated authentication/authorisation (e.g. ADFS, IdentityServer or similar), and a web API (or APIs) that the other sites can call to access other centralised services and functions programatically. I'm pretty confident you can use routing config and shared sessions to make it all hang together as if it was actually one site.
3) Build it all out as just one site, but with clear separation for the various teams about the back-end services, classes etc that they are responsible for, so they don't interfere with each other's code. Each team can check-in code to different branches in source control and only merge to the shared branches for integration/system testing and deployment. You can use a continuous integration server to test the build process after each check-in, and if you have robust code review and gated check-ins you can stop people changing stuff that they shouldn't. You also have the flexibility to release with/without updates from the various areas, if the development lifecycles are going at different speeds.
4) Some combination of all of the above!
Our product is an ASP.Net web application. Currently, we use Web Site Projects in Visual Studio, but have been looking into using Web Application Projects for quite some time. I am currently researching them so that we can hopefully improve our deployment process.
We have a base web site that is shared and common between different clients, and then we extend that with client-specific functionality in client Web Site Projects. The client projects extend base, and therefore rely on its contents. To build the full product, we first deploy the base web site, and then overlay it with the content from the client project.
In looking at converting to Web Application Projects in Visual Studio, we were hoping to be able to create the base project, then create client projects and set up references to base. This structure seems to work OK, but when we are attempting to deploy the application from the client project using MSDeploy, only the dll from the base web site is being published. This is fine for some things, referencing the compiled code is useful, but there are other items like images, js pages, htm, etc that is still source that is required for the client application to function. We need more than the compiled code from our base web site.
That all being said, I can think of a few options here:
Continue to deploy in 2 steps. First the base web site, then the client web site to build the full product.
Modify the deployment process to copy the required source files from the base project
Re-architect our model to support this base-client relationship in a different manner. Not quite sure how this would work, and would be the least-viable option.
??
Is there a different option that I am missing? Am I doing something wrong with the way I am setting up my projects? Is there more to making a Web Application reference another Web Application beyond sharing compiled code? If that's the case, why wouldn't you just use a shared class library? Or maybe I am missing something with the MS Deploy process?
I am open to suggestions here as I feel like I am missing something. I don't think our model for our web applications is too unique.
Update: The dual-deploy process does work, but feels a little kludgey. Any other input?
By using assembly WebResource you can Add CSS/JS/Some other File as Reference along with the Code i.e, your Base Project DLL.
If am right you can Add this WebResource in your base project then go through the below link.
http://support.microsoft.com/kb/910442
Like this way, most of the third party tools will access their CSS and JS files.
Try this. Hope it will help.
How is the site "shared" between clients? Does each client ultimately get a different site (ip address, etc) or are they logging into the same site but getting different functionality? You may want to looking into adding ALL the functionality into a single project and then enabling/disabling feature via settings.
If i have correctly understood your question, you'd like to publish also items which aren't compiled (htm, JS, images, etc..).
So, each file in your Solution Explorer tab has its own properties (accessed by F4 key) which let you choose the build action (eg. compile -> will inject the item in the DLL if applicable, content -> will copy the file "as is" to output directory).
I think the build action "content", with the option "copy to output directory" set to "copy if newer", may be the solution you're looking for.
I would carefully analyze what you are sharing between projects and how you share them.
If it is compiled code, the correct way is to extract those classes out into their own namespace and assembly and share the DLL across projects. Ensure you follow OO and SOLID principles while refactoring.
If it is content (js, htm, images, css) that you share, you have a few options here. You can create a separate virtual directory for the content and reference your content with an absolute URL. This helps because later down the line if you ever want to separate out a project into its own website in IIS, you don't have to change the content URLs. You can also have all the content in your so-called base website and then reference the content in the other projects using a relative path relative to the base website.
On the other hand, if it is ASP.NET user controls or ASP.NET MVC views that you would like to share, it is best to create an individual item in each project. This does not necessarily mean there is a separate physical file in that path - you can also add items in a .NET project in Visual Studio that are only reference links.
Regarding the deployment process, I don't think there is anything wrong with the web site projects per se. Web site projects have a purpose that is different than Web application projects, the main being that you do not have to compile your classes every time you deploy code (provided they are in the correct application folders).
I would suggest sticking to the 2 step deployment process with Web site projects.
I would also review the web sites (virtual directories) created in IIS and consider nesting them if it makes sense. And a review of the application pools (whether separate or shared) would not harm either.
Lastly, this is an old question. Please share if you have already implemented a successful strategy.
I am trying to create a large flex project. This Project consists of a CORE application, and other sub-applications.
The CORE application should contain information that will be shared by all other projects (e.g., link to database, data manager which loads data from the database, application information like height width colors fonts... etc.).
The sub-applications each has a certain task. Each sub-application is a large project by itself so I don't think its a good idea to put all code inside one HUGE project.
The CORE project should run the main application, and through a navigation menu, I should be able to click and run other sub-applications.
Is there a way to created the CORE application to reference those sub-applications so that I can run them inside of the CORE. At the same time, those sub-applications should reference the CORE applications to get the NetConnection to the database and other important information that they might share?
What is the best way to structure this project?
Thanks,
There's two factors to consider.
Where does the code live
Where does the compiled output of that code live.
It likely is a good idea to have all of the source code live in a single code tree. It's way easier to maintain like that. You could put each sub-application in a separate AS3 package.
It's also likely a good idea to separate the compiled output of that code. Make your core application the main flex application, and then make each sub-application a Flex module. The core app can load modules and manipulate them like any other AS3 based class. A great thing about this, is during debug time you can choose to only build the limited set of modules that you care about at the time.
I would highly suggest building your releases through some kind of automated ANT build script and not through Flex Builder.
We have one project that exceeds 150k lines of code that is managed exactly like this. That's not huge in terms of software-engineering, but it's pretty big in the Flex world.
Your best bet would be to put the CORE stuff you're suggesting into a library project. Keep the front end of the application in a Flex Application Project, but all of the data and methods that need to be shared would be easily available to the main application and all of the other modules or applications.
Then in the project settings for your main app and the other applications, you can link to the library project.
If you're planning on using a framework you can also look into the PureMVC Multicore library. It's a bit more complicated than the solution I provided above, but is built specifically to allow the sharing of data and notifications between separate applications.
It sounds like you want to use Flex modules to keep your sub-applications self-contained but still able to interact with the core application.
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html
This will allow you to keep your core application SWF fairly small and load the subapplications on demand.
Typically modules are stored in the same project as the main application but each app / module is compiled into a separate SWF either by Flex Builder or an automated build tool such as Ant or Maven.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
ASP.NET: Web Site or Web Application?
I have noticed that there is clearly a difference in what you get when you fire up Visual Studio 2008 and choose 'New Project' -> 'ASP.NET Web Application' instead of 'New Web Site' -> 'ASP.NET Web Site'. For example if you choose 'Project', then you can compile to .dll and each page gets a *.aspx.designer.cs codebehind file.
1) Why do we have these two different project types?
2) Which do you prefer?
3) Why would I choose one over the other?
4) What's the deal with the *.aspx.designer.cs files?
They have different purposes.
A website is a site with content that is likely to change over time, that is the pages themselves will change. There is no actual project file and the site is deployed simply as a set of files.
An application is a site where the content is just the application, the dynamic part will mainly be in persistant store such as a database. It will have more complex logic since its likely to represent a set of forms for data entry as much as a means to examine content. It has a project file to more strictly control its configuration and its code deployed as a compiled dll.
1) The 'web site' model was introduced with ASP.NET 2.0, the 'web application' model was the project type of the original .net framework. They both have different uses (see below).
2) It depends on the context. A good example is if you are selling a software product, you may wish to use a 'web application' project because it naturally lends itself to cleanly compiled code.
3) See above, personal preference, maintenance characteristics. An interesting thing that a 'web site' allows you to do that can get you in a lot of trouble is making arbitrary changes to code-behind (typically a *.cs or *.vb) file in notepad while the website is running.
4) The designer.cs file is used to store the auto-generated code. "This code was generated by a tool."
MSDN Article describing the differences
Similar stackoverflow question
I won't duplicate the definition of the 2, since that just got answered.
So why use one over the other?
Web Site lets you treat it like a PHP or classic ASP site, where you can make inline changes that take effect immediately.
Pros
You can make tweaks to the site right on the web server
Deploying is as simple as copying the folder
Cons
If you are not making the changes right on the live site, you can get into change management problems, where you forget to keep all your files in sync
You can get runtime syntax errors displayed to your end users, since the only way to check is to manually run every page
Web Application lets you treat it more like how you would a desktop application - there is one deployable that is compiled on your machine.
Pros
Clear, structured change management. You cannot accidently mix code from two different versions. This can be important when there are 2 people involved - one writing the code, and one responsible for putting files on the server.
Because you compile it on your machine, everything gets syntax checked at that point*
Cons
Deployment is a little more involved then just copying the folder from your development machine. However the usage of the "Publish" command greatly simplifies the process of compiling and putting together what files should be copied to the web server.
Any changes need to be done on your machine, compiled, and a whole new version sent to the web server*
*The aspx/html files are only syntax checked if you turn this on in your build options though. It is also possible to edit these files on the server unless they are compiled into your project.
The simple answers are as follows:
New Web Site - creates code behind pages that are compiled at the server when page is requested.
New Web Project - creates pre-compiled pages into one or more assemblies (entire site even), and deployed on server.
Scenario #1 - If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.
Scenario #2 - if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.
For more information:
Introduction to Web Application Projects
3) WebApplication projects are buildable by MSBuild. WebSites are not (without a lot of tweaking). If you use TeamSystem with automated builds then this is the way to go.
THe biggest difference that no one has really mentioned (except touched on by Annakata) is that with the model where everything is compiled into a single DLL, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.
With the single page model, you can't do this. You have to get around it by creating "stub" classes in the AppCode directory, and inheriting those in your pages, but even that isn't ideal, and add complexity.
You'll only really come up agaist this stuff if you're trying to develop an intricate dynamic site, where you dynamically load lots of user-controls at run-time based on content. Then, the differences are painfully clear - hence much of our development stalled on ASP 1.1 until we could go back to the same model later.
Nich
Speaking from experience with both: "Web Sites" are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes "hotfixes" to specific pages regularly. "Web Applications" are the de facto standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a "hotfix" arises.
Sites are the 2003 original .NET way of doing web dev. In my experience they are extremely problematic since lacking a project definition they can't be reused and have issues with modular coding, have issues with TeamSystem integration and namespacing. The one-to-one bind with a domain and lack of real publishing abstraction creates maintenance problems down the line.
The ancient "classic" ASP way of !codebehind is a serious problem because it again impairs code reuse and testing, and the often cited benefits of allowing hot fixes - if ever called upon - is actually a massive signal that you have a failing development process. The ability to hot fix is of course better than not being able to, but it's something you never want to invoke.
You might say that the problems with the web site model were great enough that MS gave us web apps instead. Personally I would never use them for anything beyond demo code... no actually I wouldn't even do that.
At first there was a Web application project (it behaved similarly to the current Web site project). They changed it to reflect what some users requested. However people wanted the old functionality back so they re-introduced the Web site project which behaves like the original Web application project.
I -- and my workplace -- prefer the Web site project
We like that the files of the website are the files in the file system (no need to add them manually)
No idea
Here's two articles I found about both:
http://damieng.com/blog/2008/02/07/web-site-vs-web-application
http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx
Note: A lot of the issues with Web sites have been resolved with the Web deployment project
Update: Fixed the point 1, Web application was there first
If your work needs to leverage oo language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.
The website project (the clue is in the name) is only really good for non-complex 'brochureware' sites (where the pages consist of static content) as opposed to web applications.
There is very little difference, and I would highly recommend using the Web Site model.
The main difference is for a website, some files need to be placed in certain directories (code files need to be placed in the 'App_Code' directory), besides that, it's pretty straight forward.
If having compiled code for deployment is important to you, and you want a single DLL (opposed to the several that are created when you do a normal publish for a web site), then you'll want to get this add-on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx
I'm doing some work with several shared .NET assemblies and a generic web application that I would like to handle better in our CC.NET/NAnt build environment.
Currently, we have several .NET assemblies (shared common code that we use in client projects) that exist in different .NET solutions within different repositories in our SCM (Vault incidentally). They are all configured under CC.NET separately so we have a decent amount of control over their build and deployment at present.
We have developed a CMS system that uses some of the .NET assemblies and includes a common administration website project and a template website example project. Out of this one solution we have the following elements that need to managed separately:
Admin interface is not tied to .NET so it is template based and we are developing a PHP backend for it currently.
CMS shared assembly build on top of our other common company wide assemblies.
Control over functionality within each major CMS build/release.
I'd like the build output of this solution to be a Visual Studio template, which we can use to develop other client sites and better manage version changes within the CMS itself, as we add features to the codebase.
I have a rough approach for all this and think it is achievable, however, I wanted to open this topic up for discussion and see what everyone else is doing when it comes to managing the build and deployment of multiple solutions.
Main considerations for us are:
Do we make use of the integration queue functionality in CC.NET to ensure a build order and pull together the assemblies we need for the CMS at build time?
Debugging within a CMS client site i.e. stepping into the shared assemblies' code when the client solution is a version of the base CMS system and therefore separate.
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
Any other issues people might have experienced that could change our way of thinking?
Hopefully this question isn't too vague and some of you will have dealt with these issues. Look forward to hearing everyones experiences.
Many thanks!
Tim
I unfortunately cannot answer all of your points, but let me start with this one:
Do we make use of the integration queue functionality in CC.NET to
ensure a build order and pull together
the assemblies we need for the CMS at
build time?
The short answer is -yes, you should. The queue attribute ensures a build order within the running instance of CC.NET and is gives you serialization of the builds that depend on each other. For specifying which projects depend on each other, you should use project triggers. Do not rely on the queuePriority for this task.
You shold most likely pull the pieces you need to do the build at build time. Unless you have some time constraints on your individual builds.
Re:
Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?
I'm fundamentally against distributing binaries in the trunk unless it's some libraries that does not need to be updated/changed on a frequent basis. If you build the shared assemblies yourself, you should consider pulling them from the artifacts on the build server(s).