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.
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 1 year ago.
Improve this question
I'm working on a C# app that makes use of interop to interact with several of our DLLs that export C-linkage functions. Because our product consists of more than one executable, I moved all the interop code and many shared classes into a C# class library, and reference it in the C# executable projects.
I'm considering breaking this monolithic C# class library up into a few, more granular class libraries for a few reasons, including:
When I initially set this up, it was less clear which executable projects would need which classes. The app has matured somewhat since then, and it's now clear that a significant percentage of the classes in the library are only used by a single executable...
Our C-linkage DLLs have dependencies that very occasionally fail on a user machine[1]. That prevents all our executables from running, even the ones that don't make use of that particular DLL.
Startup time for our primary app is high (> 2 seconds). As soon as we use anything in our .NET class library, (I think) it loads everything (DLLs included).
My question is about the factors to consider before deciding whether to stay with a single class library, or break things up into smaller, more independent libraries. For example, is the per-library overhead in (runtime) resource footprint or loading time significant enough to affect the decision?
[1]: If they have a broken driver install, for example.
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
A "God Namespace" is the (uncommon) term for an (anti?)pattern analogous to the "God Object", when you stuff a metric ton of stuff (mostly methods/functions) that is not related or not closely related to each other into one huge namespace/static class just so that it can be used in multiple sections of your project.
When following that (anti?)pattern, you often end up, as a C# example, with something like a static class Assets with tons of methods mostly unrelated to each other, but used across multiple places in your project(s).
I usually approach this problem by letting the next Assets grow for as much as I can bear it, and then desperately try to sort its contents out into several smaller ones based on the criteria which seems most legit, like MathAssets, or BitmapAssets, or RNGAssets, and then end up forgetting what did I put where... and make a new Assets for several new methods which don't fit into either of the SomethingAssets already cluttering up the project.
Are there any other ways of clearing up the "God Namespace"? Or will I just have to live with good old static class Assets?
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'm being tasked with making a modular program that uses external, easy to edit files to dictate if certain elements are shown, what classes are used, etc.
Using C# and Visual Studio 2008, what type of file should I use? I was suggested .ini, but there is also talk of using .xml for it?
Which file would be best, and is there a built-in C# method of working with those files?
There's a heap of different ways for achieving different things. You could for example use an appSetting in an app.config file to turn features on and off. If you wanted to change classes or services that are used, then you could use DI/IoC with something like Castle Windsor and configure that in code and or xml.
If you can be more specific with what you want to achieve, and some examples in code, you can probably get some better answers.
you can use custom sections in your config files.
Config files are xml, well known files in .net context.
See example here: http://msdn.microsoft.com/en-us/library/vstudio/2tw134k3(v=vs.100).aspx
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 3 years ago.
Improve this question
A trivial question perhaps, but I'm interested in the answers. I'm currently refactoring some very large monolithic string resource files (one dumpster resource file per project, in about 30 projects). I'm splitting them such that we follow a convention for our files and make the strings easier to find and manage when coding.
Generally I'm splitting the files into this scheme:
ErrorMessages.resx
LogMessages.resx
ViewResources.resx
AppResources.resx
I'm not terribly thrilled with the naming, and I'm just wondering what other people use. For example, instead of AppResources (strings for internal use by the application), I've seen a lot of demo projects use StringResources, Internal (terrible!), etc.
Ideas/anecdotes/suggestions on managing resources or standard naming schemes are appreciated.
I generally structure my resources like this:
The first resource file is used by the entire application (e.g. Project.Core) and does include all sorts of widely used common strings. I actually don't make any difference between errors/exceptions and logging:
CommonResources.resx
Access modifier: Public
Error_Contexte.g. Error_ArgumentCannotBeNull
Warn_Contexte.g. Warn_ApplicationSettingNotFoundUseDefault
Info_Contexte.g. Info_UpdateAvailable
Validation_Contexte.g. Validation_EmailNotValid
The second resource file is used by the presentation layer and contains all sorts of UI strings. The naming can vary from project to project but generally it looks like the following schema:
PresentationResources.resx
Access modifier: Internal
Common_Contexte.g. Common_Yes
Section/Controller_Window/View_Contexte.g. Help_FAQ_HeadlineHowToUseResources or Help_FAQ_TextHowToUseResources
Finally every project/assembly does also have an internal resource file for Error/Warn/Info/Validation resources that are too specific to go in the CommonResources.resx file. I have to admit, that I mostly name this resource file InternalResources.cs ;)
InternalResources.resx
Access modifier: Internal
Classname_Error_Contexte.g. BCrypt_Error_InvalidSaltRevision
Classname_Warn_Context
Classname_Info_Context
Classname_Validation_Context