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 7 years ago.
Improve this question
i am now developing a c# solution with 5 projects.
When i created the project under the solution, each project has its own namespace. My question is should i unify the namespaces using the solution namespace to avoid any scope problems later ?
Besides, i have a project for the Win Forms and using folders under it (to organize the forms). Each folder has several form.
When i want to use the form, i found that i have to mention the folder also.
What should i do then ?
Namespace is not related to the project structure but it is good habit follow the project structure. This make orientation in code much better. There is no need to unify namespace from scope reason. It should mirror your logical project layout. eg. your namespace can start with company (or product) name and than follow with component and then follow with your structure:
MyProduct.DataLayer
MyProduct.UI
MyProduct.Tools
MyProduct
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 have been working on a project in Unity, and was trying to figure out how to abbreviate a large number into a more readable format. I found somebody who asked the same question and got some code, but the person who gave that code had 2 classes in the same C# script. I am new to Unity and C# in general, so this was not something I had seen before.
What I would like to know is when to put classes in different scripts, when to put multiple classes in the same script, and if I do put multiple classes in the same script how that affects that script and other scripts in the project.
From a C# logical point of view, it does not matter where a class is. From the practical perspective, it is usual to put every type (class, struct) in its own code file. I often make an exception for enums and put enums belonging to the same realm into the same file, e.g. things like DisplayStyle, SortOrder, Visibilty could be in a file named AppearanceEnums.cs. Enums are mostly small and don't contain logic.
for Unity, see: How to architect code as your project scales
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 6 years ago.
Improve this question
I have 2 separation solutions. One is done using MVC (Solutions 1) and the other is done using Web Forms (Solution 2). I have a class in one of the solutions (MVC one) that I like to use in the Web Forms solution. How would I reference the class in Solution 1 through Solution 2?
It depends on where the class is located. Ideally you would move your class out into its own project so that you can add the project to the other solution. You could also add an existing item from your MVC solution but this can lead to all kinds of dependency problems and shouldn't be done.
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 6 years ago.
Improve this question
Another developer at my company created a new class library using the following namespace:
MyCompany.Repositories.Users
Based on my experience over the years I would expect this namespace to be named as:
MyCompany.Repository.User
Which style do you normally use for your namespaces? I was thinking my style was somewhat standard. It looks cleaner to me. Can you provide any authoritative urls which recommend namespace naming conventions?
Interesting question. I've never seen any advice beyond "use plurals where appropriate" for C#.
Let's assume that the namespace is MyCompany.Repositories
Borrowing from a similar question posed in the Java world I would suggest that plural is valid. The components that live within the Repositories namespace will be homogeneous in the sense that they are all repositories (UserRepository, StudentRepository, LocationRepository, etc).
Conversely, a namespace like MyCompany.ReportingEngine would be valid as a singularly-named namespace, as this namespace may contain heterogeneous classes that do very different things (IE a query generator class, a report model, a field model, a filtering model). MyCompany.ReportingEngines would suggest that this namespace contains different types of classes that are reporting engines.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I am given a source control which comprises class libraries only.
How should I run the project?
You can't debug a class library directly. If you think about it, where would it start running, i.e. what method? You need to have an executable (console application, winforms, wpf, etc.) project to run, which would typically reference your class library.
If you have one of those in your solution, right-click on it in the solution explorer and select "Set as Startup Project". Then try again.
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 8 years ago.
Improve this question
I just am a bit confused regarding what is right and wrong or rather what is the recommeded practice.
I have a class file A.cs which contains an abstract class.
I want other classes which would be located in other Dlls to reference to this class.
Hence what is the recommended practice?
Do i create a dll which contains this class and other dll's would reference this dll.
Or do i include this class file in every dll so that references are set correct (considering all dll projects reference this cs file from same location)
What is the recommended practice? What are pros and cons of same?
Think of your Object Orientated design principles. SOLID and DRY.
Write it once and reuse it.
As for where the code resides i.e. in which assembly, it's really down to how you organise your code. Does this piece of code need to be used only by code in this assembly? Does it need to be shared with others?