Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I will create four projects each other works together.
desktop program ( as User Interface for entering datas )
web site ( for reporting )
web service ( for connecting database - from desktop program and reporting portal )
windows service ( for sending datas which are entered by users via desktop program to database )
Should i create one Visual Studio Solution which contains these four projects, or should i create different solutions for each of them?
What are the advantages of creating just one solution ?
Thank you.
For what it's worth, here are some significant pros and cons which may affect you:
If you put them all in the same solution, it will be very easy to share code between them-- e.g. projects in a solution can reference another project assembly in the solution as a reference directly, making debugging very nice. Nuget packages will share a common folder if they are shared, and you can see everything nicely at the same time.
However, if you these are programs that run independently but interact with each other, debugging is sometimes easier if they are in separate solutions, so separate copies of visual studio can be debugging the separate pieces simultaneously.
With one solution you will need to start only one VisualStudio instance, where you access code from different projects at once.
All possible refactorings(renaming, signature changing etc) can be easily done when you using one solution. With different solution you will never know if you remove/rename some code used by project from another solution.
You will be able to build all projects at once. Execute all possible unit and integration tests (if you have such)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am creating the service where I am using DI container as an entry point.
My solution is getting heavy what forced me to think how to do unity registration in good way.
I have Service with couple of other dlls with logic. As for now, Unity is installed only in Service where all registration is done.
My service needs to refer all dlls which are needed for DI registration and all nugets installed and used by refereed dlls in DI.
It ends up with pretty heavy packages.config in Service which are needed only for DI registration and it is hard to recognize what is used by service itself and what is not.
I am wondering if there is other way, more cleaner way to do registration without huge list of references in main project and do not brake good practice roles at the same time.
I came up with two solutions:
1 - Create separate dll only for UnityConfiguration, I could have there one public static class like: UnityConfiguration.RegisterComponents() which would be called by Service. In that solution I still will have huge list of reference to all the stuff, but it will be at least separated from main service...
2 - Solutions which probably will not be supported by anyone (by me as well): I would have Unity installed in each dll with logic and each dll could have its own static class UnityConfiguration.RegisterComponents() and main service would call all that registration without knowing the types...
Can you please share your way you would go for ? I am really interested in your opinion...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a big Windows Form Application which works as a machine configuration software and that interacts with the user, collects the data from the machine and operates on a SQL Database with 15 sub projects associated with it. It was developed with a singleton pattern long back.
Additionally I have a WPF Application developed recently with MVVM which is used to interact with the Database with a back-end project to get data from the database and display meaningful results to the user.
Now, I would like to know, if it is a good programming practice to combine both WPF and Windows Forms Projects under one solution. Will it result in longer loading and build times ?
I am using Visual Studio 2017 currently.
Now, I would like to know, if it is a good programming practice to combine both WPF and Windows Forms Projects under one solution. Will it result in longer loading and build times ?
It's common to have several different projects, including several different client applications, in the same Visual Studio solution. You may still deploy each executable separately.
Obviously the total build and load time will increase (at least in theory) for each project that you add to the solution but this shouldn't be an issue considering that you only need to re-build projects that have actually changed since the last build during development.
To answer your question, it's not considered a bad practice to have several client application projects in the same solution.
You may also have several solution files, e.g. one solution that contains all projects and a WPF solution that only contains projects that the WPF application uses and so on. This is what I usually do when the solution consists of 100+ projects.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
For my company, I have developed one winform application, that handles Unified COmmunication.
It's been 1 year in development. I Just write global functions in seperate classes, and write the code in either form or class. Now They wanted me to make three seperate copies(UI of each changed) of the same Software. I have changed all UI and everything needed, and made 3 copies. But now, I feel it very difficult to correct any issues, or add any features. I have to change it in my all three copies. How can I solve this. Thanks.
I'll assume the three versions are very similar. First off, it's of the utmost importance that you keep your project under source control.
Personally, I would have created a dev branch for the main version, and then create two other branches for the 2 other versions (e.g., dev-v1 and dev-v2), created off the main branch.
Then, whenever I had to apply a patch to all 3 versions, I'd do it on the dev branch, and then merge dev with dev-v1 and again with dev-v2.
So far I only addressed the source control issue, but as CSharpie pointed out in the comments, you should definitely separate the presentation layer (i.e., forms) from the business logic. Furthermore, these two should also be separated from the data layer.
Take a look at Multitier architecture.
Separation doesn't necessarily mean different projects or solutions. Having a logical separation (e.g., having sets of classes with very well defined purposes, following the SOLID principles etc.) is often enough. In your case, however, it seems that the presentation layer should be in a different project than the other two.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am going to be creating a web application for internal company use. I created one "General.dll" class library that contains abstract classes such as Person, EmailAddress, etc. And then I created an "EmployeeManagement.dll" which includes classes such as Employee : Person, EmployeeEmailAddress : EmailAddress, etc.
My EmployeeManagement.dll references and relies on General.dll.
Then my web application will reference EmployeeManagement.dll.
How can I effectively keep track of cascading changes? For example, if I make a change to General.dll, I will need to recompile that class library into a new General.dll, and then remember to reference the new General.dll in every other class library that uses it. Then those libraries will need to be recompiled and I have to remember to update the references in the web application to those as well...Seems like there must be a tool or more efficient way to handle this that I just don't know of. Any tips?
For a start, if you add all of your projects to the same solution in Visual Studio then they will automatically be rebuilt as appropriate based on dependencies when you make a change.
Also, during development you probably don't want to add a reference to a particular version of an assembly (this is the default when choosing 'Add reference'). In this way, any changes to your General.dll will automatically cascade to any other project that references it on the next build.
Edit after update from OP
You are quite free to reuse projects in different solutions. So you can have exactly one codebase for General.dll and include that project in any solution that needs it. In that case you of course need to be careful when making changes to General.dll to avoid potentially breaking any project that includes it (a continuous integration utility can help here).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have three projects(C# libraries) namely A,B,C.
All the 3 have 3-4 xml files(in general can be resources) associated with them.
Each of these projects have classes that access these files for settings and information.
(loading xmls when ever they need)
The problems is sometimes there is a need that a class in project C may need to access
resources(xml files,images etc) of project B and vice versa.
Also these files may or may not be a part of the project solution.These resource paths
can come from app.config etc.
Its really becoming tedious to work out how to centralise access to these resources so that
all three projects can access them uniformly.
Currently all the projects load the files using app.config.
Also i'm trying to minimise the number of times a xml is loaded.(ideally once).
But given the projects are different i have to load it again.
I thought of using a Singleton class as it would make more sense for making uniform access but haven't quiet figured out a way.
Anyone has come across similar situations?
Are there any design patterns or best practices for sharing resources across projects?
Create one library containing the class(es) that access your centralized XML settings, and reference that library from the other libraries.
You don't necessarily need a Singleton for this, but putting it in one place will allow you to focus your efforts on things to improve it later, possibly caching, etc.