I've been trying to find some clear documentation on best practices with regard to nesting Visual Studio solutions. Please bear with me if the terminology is wrong - I'm not really experienced in creating significant solutions.
Here's what I'm trying to achieve.
I have a website that is a web application in VS speak - so it is my solution.
The site will have some reusable functionality. Normally I would just create a class library project and have done with it.
However, in this case the functionality is database driven via Entity Framework. If I was creating a self contained project, I would create a new solution, containing 3 library class projects for BLL, DAL and Entities.
So instead, I'm thinking a second solution containing the 3 class libraries - obviously I don't need a second front end as the primary web application will do the job.
So, I have a number of options as far as I can see:
Create a new solution as described above that can be plugged into my
main solution - but what do I do with the unwanted project that
contains the App_Data, Account folders etc?
Create a single class library and create visual separation through
folders.
Create 3 separate class lib projects (although this gives least
benefit)
Or, something else I'm not aware of.
Sorry if this sounds basic to you guys that do this day in day out, but I just don't have the necessary experience to make the right call.
Related
I'm planning to create a website using ASP.NET Core 2.0 , Entity Framework Core, Angular.
I was planning to create one solution with different projects (core, data layer, UI ...etc ) however the client quoted "this is a bad idea, please create separate solution for your UI and API).
how can i create multiple solution and still let them interact with each others?
What is the best practice?
If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?
Solution is basically just a logical container for projects, so you can create multiple solutions which will reference the same (existing) projects. This is quite common for large solutions like for example Xamarin.Forms - you can have one large solution with all projects and then have smaller solutions for developers who need to work with only a subset of the projects.
You can add existing project to your solution by right-clicking the solution in Solution Explorer and choosing Add - Existing Project.
I think your client may misunderstand what a solution is. Grouping your projects in a solution only affects your workspace in Visual Studio, it does not mean that your projects have dependencies between them (unless you explicitely say so in their references)
The only way I can imagine this working is to deliver each solution as a set of microservices.
However, now your architecture is different. Only one of those solutions is going to be publicly exposed. The others will need to sit behind a firewall to ensure that they can't be reached by external users. But all of them will have scalability and security concerns.
So you'll have a set of data services that encapsulate Entity Framework and expose the data through a Web API, and a business logic API that is reached over a Web API, and then your UI (which should include Angular).
APIs calling APIs. Welcome to microservices.
how can i create multiple solution and still let them interact with each others? What is the best practice? If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?
Answer :
Create base solution first ex : BaseSolution.sln then go to that solution file explorer and create API,UI folder.
Now open visual studio and create new solution ex: ApiSolution.sln save it under API folder and add web api project inside ApiSolution.sln and save.
Now open BaseSolution.sln and right-clicking the solution in Solution Explorer and choosing Add - Existing Project then choose web api project from ApiSolution.sln then add it.
You can follow step 2 and 3 to create more solution and add it to BaseSolution.
Web api connect through HTTPClient with another web api.
I'm busy on a small project to convert an Access2003 db to .NET. I am trying to integrate my functionality in an existing project that is being used for Administration of some kind. The code in this project is VB.net.
I started by setting up my Data Access Layer, which seems to work fine. I can make new web pages that access the data I need. However when I start to use class files to set up my Business Logic Layer I can't build my project when using C# instead of VB. I dislike VB and like to program in C# as I know the syntax a lot better, etc. Is it possible to program using C# knowing that VB.NET was the language chosen to build the entire project on?
If not, what will be the smartest way to integrate my module into the project using my favorite programming language? (Make a project and reference to the dll?)
Edit: So the next step in my question would be -->
If I set up a new project within the existing solution, can I make that new project contain my Business Logic Layer + Data Access Layer and reference from my existing one?
Yes, you can't mix languages within the same project, but you can add as many projects written in different languages as you like, to the same solution. (This is sometimes very useful, especially when it comes to having portions written in C++/CLI, which are able to do things which would be impossible to do in C#/VB.NET.)
I have a scenario that i have never come across and as such require help. I created an Visual Studio Web Application. The solution had two parts.
Project that holds all the UIs and
a Model that contain my c# code.
The objective was to achieve a 3 tier architecture. The model being the middle tier. The project is running and everything is awesome. NOW! This is my situation and I dont have an idea on how to approach it. I have to build another application, which basically is an extension of the first one. So how I went about starting this was to add another WEB Project to my currently solution. This had a lot of problem. When I deploy the project two web pages would load (one from each project). What i want is ONE webpage to load and base on your userId it will send you to the appropriate location. What I also saw was the second web project i added needed it's own users. How it should be is.. one set of users each having specific access to the application (which ever part). I need input on how to go about getting this done.
What I want is to debug 1 solution (with the 2 parts/projects). Base on userId he/she has access to a specific project but there is one user list that governs the entire solution and not two list, one for each project.
Is there a problem just adding pages to a directory in the existing web project? Normally, separate projects would be deployed as separate applications, not as merged into the same application. You can control access using web.config files in the "secured" directories
Another Architectural suggestion would be to create a Main web project that was sort of a wrapper if these applications are extensive enough and functionally dissimilar enough to warrant separate projects. This would be where your routing logic would take place and would provide simple stub directories for your paths (user-type 1 ... user-type n). Then you can create a project for each of your end paths and set some build actions that take the output of the sub projects and copy them to the output directories for the wrapper project, but this gets pretty complex.
I would still recommend keeping this as a single project if it is to be deployed as a single web application.
While it's possible to make this work as two separate systems, it's really a lot more headache than it's worth in most cases.
The question you should ask yourself is, is it really worth it to do this? What are you gaining from it?
This article explains how to do this:
http://support.microsoft.com/kb/307467
Another option is to create sub-sites, which is to add your additional project as a child. This is described here:
http://abhighag.blogspot.com/2012/03/separate-web-application-into-multiple.html
Over time, the code base I maintain has grown exponentially. We have a variety of different utility classes, webparts, event receivers, console applications, and more.
Typically, each webpart lives in a separate DLL (one solution and one project per web part). Our utility classes have also been largely separated out into their own separate DLLs (this includes any specialized list access classes that get grouped with their beans together in a DLL). This has led to a large amount of solutions which has become more difficult to maintain (upgrading each solution to Visual Studio 2008, or simply just trying to find out the maze of DLL references).
With my discovery of the SharePoint Guidance, I'm re-evaluating our current code structure. For example, it looks like they recommend combining all of your specialized list access classes into a Repository (we've done completely the opposite so far by splitting them into DLLs based on what "solution" the code is for).
Questions: How should I be organizing my code? How do you decide what goes into a solution vs project vs folder or what goes in a namespace? One solution per web part?
I usually organize my code by functionality. Let's say I've got an extranet project and some code for some intranet webparts, I seperate it out into a Extranet and an Intranet project, and seperate the different classes of code (eventreceivers, timerjobs, webparts, etc.) into different namespace.
That way, I can deploy (sub)sets of functionality to different farms if I want to, and when editing code I got everything that depends on one another in the same place :)
I googled this a little but couldn't find a good result.
Right now I'm building a web site and I'm trying to make it as correct as possible from a design point of view from the beginning.
The problem I'm now facing is that when deciding to start with logging I needed a project to place this code in. As I could not find a suitable place in my currect projects I thought: hey, why not a logging class library?
Is there a general guideline on how many projects you should have? I know this would be a rather small project but it would be nice to entirely get it out of my way!
Any hints are appreciated :)
Absolutely you should have a logging library. And if you're going to make this as 'correct as possible from a design point of view' and your proect is less than trivial then you should definitely have some number of projects. The thing is, we have no idea what you're working on besides the fact that it's a web app. It's the biz domain that often determines how complex your solution has to be.
I'd go for a three-tier architecture for a small project.
This would include:
Application Layer
Business Layer
Data Layer
but if you want to add logging, it would be best to create another project. This would also help you so that if you want to add logging to another application, you can just include the logging project.
Either way would work, if you are concerned about project limit in a solutions. Don't be.
I myself would put it in a separate project or a utility project.
We have a solution with 200+ projects. The downside is long load time in Visual Studio. But past that the only issue is making sure you have enough RAM.
Also, MSBuild.exe has built-in support for SLN files, so look into using that instead of Visual Studio if you are doing automated builds.
"That which changes together should be packaged together", I forget where that guideline comes from (Code Complete maybe?).
In other words your assemblies (projects) should represent a coherent abstraction in the same way your classes/objects do at a lower level.
So yes, a separate logging project is the right way to go (although do check out log4net or Microsoft's logging block before you roll your own!)
Put a logging into a separate project is perfectly fine.However it really depends on the scope of your project.I normally setup my project like this
YourProject.Web(web project)
YourProject.Core(all the business logic)
YourProject.Web.Tests(Watin tests)
YourProject.Web.Core.UnitTests(Unit tests)
YourProject.Web.Core.IntegrationTests(Integration tests)
I suggest you to download some open source Project from asp.net to see how the project have been organized.