So I have files that are used in multiple projects (in one solution). Which way would I choose?
Embedded Resource and use with Assembly.GetManifestResourceStream
Add file to Resources.resx and use with Properties.Resources.
Copy to Output Directoryand use the known path to read
Linked Resource?
Right now the files reside inside a Resource-Folder in the root directory of the solution. But this way there is no relative path to these files.
I could add them to properties/resources but to which project? There is no "main" project that handles these files. Or create a new "ResourceHolder"-project just for resources?
If I add them to multiple projects they are all copies and not links to the original file/path as far as I know... so that's also no option.
Can't you add resources solution wide? Or better have a solution wide folder and only if a project uses a file it is then copied to output and can be used with a relative path?
There are no solution-wide resources, because there is no artifact produced by the solution itself. The place to put the resources depends, in my opinion, on the semantics of the resources.
If they are, for example, icons, which must be consistent over several assemblies (i.e. over several controls that reside in different assemblies or several different applications belonging to a set of applications), then they semantically are global resources. Hence, I would put them into a separate resource assembly that is referenced by all other assemblies.
If they are separate resources that just happen to be the same right now (i.e. test data for different test assemblies), then they have, in my opinion, no global semantics and should be copied into every project which requires them. This would then also allow to distribute the resulting assemblies independently as they have no further dependencies on each other.
Regarding your third option: I would always try to avoid working on files directly. This only may be applicable in two scenarios:
First, if the files do not belong to the application, i.e. they are user data (such as documents read and written by the application); that doesn't seem to be the case her.
Second, if the files are so large that duplicating them would result in a substantial demand of disk space. Your question does not read like that's the case, but in such a situation it might be feasible to provide a central repository of the data.
Related
I am trying to figure out whether a global string resource file for the entire application or a local resource file for each small sub area would be a better choice.
It seems like a translator would appreciate the one file approach vs hundreds of them. It is also easier to write helper functions since there is only going to be one static resource class.
The downside is that the resource name might be really long to properly identify the place where it is suppose to be in and it might be hard to locate related strings when the file grows big.
Where as a local resource file would produce lots of duplicated strings or make it confusing if we need to use multiple instances of static resource classes because the strings are spread between multiple of them.
So what would be a better way to go?
Maybe you could break your resources into 3 files (depending on your application design):
ResourcesCore
For translated enum values and common expressions
ResourcesEntity
For strings related to translation of some entity properties (e.g. Person.Name)
ResourcesWeb (or ResourceUI)
For other UI related stuff (like strings on UI, labels, descriptions, etc.)
You could then use ResXManager extension for VS to manage you resource strings (way easier than native .NET ResX manager, at least for me).
I am building a multi-language MVC application and have a series of resource files with translated strings for messages that will be displayed to the user.
Is there any way of ensuring that any resource files added in the future have all required keys and are spelled correctly?
As an analogy, if the resource file was a regular class, you could provide an interface to ensure that all required method and properties were present in the implementing class. Is there a similar concept for resource files?
I've been unable to find a supported way to enforce an explicit contract upon a .resx file. Since your goal is ultimately to catch implementation errors before they show up at runtime (and compile time checking isn't possible), I recommend falling back to static code analysis. Luckily, .NET makes this trivially easy:
Use the System.Resources.ResXResourceReader class to read the contents of the resx files to be validated.
Implement a test that asserts against all required keys in the "contract" you'd like to enforce on the resx.
Test should run as part of an existing test suite, and failure will warn a developer of the implicit contract before encountering the problem at runtime.
Since your resource files will exist in a known location, you can trivially ensure that the tests run against all resx files in that directory. In this way, you don't even need to update the test when new resource files are added, only if the contract changes.
I've used a similar approach to help with maintenance of stored procedure names kept in (an extensive number of) resx files. Since the resource files are spread across dozens of projects, manual maintenance is tedious and error-prone -- in other words, it doesn't get done. The static code analysis approach has yielded few downsides, and I think it would work well in your case as well.
Landing page for resource files on MSDN
ResXResourceReader on MSDN
System.Resources.ResXResourceReader requires a reference to System.Windows.Forms. It's available on both .NET and Mono.
I'm creating a library for use with an application that I am building. I am building a name space structure similar to below.
MyNamespace.Validation
MyNamespace.Reports
MyNamespace.Transactions
MyNamespace.DataImport
etc...
Would it be best practice to create a solution with multiple projects for each sub namespace or one project with multiple class files for each sub namespace? Thanks.
There are pros and cons to both approaches, which you need to personally decide between for your own circumstance.
Pro to multiple projects:
Separate assemblies allow the compiler to provide more strict guidance, potentially preventing coupling from creeping through. This allows you to maintain the dependencies better.
Separate assemblies can be loaded as needed in other projects, potentially easing reuse.
Separate assemblies can prevent unnecessary code from being loaded into a process, since they're loaded on demand.
Cons to multiple projects:
More complex deployment, as more files need deployment (minor)
Slower build/compile, and even potentially load times from loading multiple assemblies (minor)
Personally, I think the pros far outweigh the cons in most cases. I typically will split my namespaces into separate assemblies, provided they are not related. In your case, you're working on 4 very different concepts, so my gut feeling is that splitting makes the most sense.
I would say it depends.
First, it's best practice to put each class in its own file.
If you go with one project, I would create folders for each namespace inside that project, and put the code files in the appropriate folder.
Doing the above, Visual Studio will automatically create new class files within the correct namespace
I think the real question here is this though:
If this is only ever going to be used once, putting everything in one project would make sense. However, if this code is going to be reusable, you should think if you would ever reuse just a part (or one sub-namespace) of this library. If the answer is yes, I would break apart the namespaces into separate projects, so in the future, you could only include the projects you needed.
I would go for the one solution with multiple projects.
Advantages:
- Each project can be a separate dll
- All projects in one solution for easy navigating between files
Deciding exactly how to break up your solution is subjective - and it really depends on the specifics of your code.
However, one thing is certain: maintaining multiple assemblies has drawbacks! This article is particularly good at describing those drawbacks, observing how they add costs at development time, compile time, deployment time, and runtime.
I use as few assemblies as possible, aiming for a single assembly while isolating volatile areas of the domain. When multiple assemblies are clearly appropriate or required (and they often are, particularly to enforce decoupling), I do my best to group interfaces that will change at the same time into the same assemblies.
I have usually followed the pattern with one assembly is one namespace and the DLL name is in the namespace. Easier to find what DLLs to reference
Is there a recommended process for creating reusable ASP.NET assemblies that contain UserControls that can be shared across projects in separate solutions?
We have currently have a set of post-compilation steps that run aspnet_compiler.exe on the project, generate the precompiled assemblies using a given name, followed by aspnet_merge.exe to combine each individual control assembly into a single assembly - which is then copied into the bin directory for the project.
Unfortunately, user controls compiled in this manner don't 'play well' with the VS designer - and throw exceptions at design time that make working with pages that host them cumbersome.
Is there a better approach for doing this?
That is the only approach that will put them into a portable stand-alone assembly like that. Sounds like you already know everything referenced here, but this is the best article I know of that discusses the technique:
http://blogs.msdn.com/davidebb/archive/2005/10/30/487160.aspx
What I've always done is just require the ascx to exist, too. The code-behind can be in the portable dll, but still require the ascx. You can help manage duplicates by keeping them all in one place and mapping virtual directories to that location. The advantage of this approach, even though it is low-tech, is that each app if it wants could customize the ascx's look. It could move things around or change the styling, etc, and the code-behind would be none-the-wiser as long as the changes didnt affect which server controls exist.
I am reorganizing my source files into a single solution with a single project, due to various reasons:
a paranoic configured antivirus software;
Advices on partitioning code through .NET assemblies
Control component dependencies to gain clean architecture
Benefit from the C# and VB.NET compilers perf
This leaves me with many namespaces, which are splitted across multiple files. So far, I am using this convention: given the namespace Company.Project.A, the files are named A.f1.cs, A.f2.cs and so on, and the Company.Project.B namespace is splitted across B.f1.cs, B.f2.cs, etc.
Given the single project restriction, are there any better ways to organize multiple files in multiple namespaces?
Yes - use folders.
If you create a folder within a project, new classes within that folder will automatically use the folder name as the basis for the namespace.
For instance, if you have a project with a default namespace of "Company.Project" and a folder "Foo" containing "Bar.cs" you'll end up with:
using System; // Etc
namespace Company.Project.Foo
{
class Bar
{
}
}
So the solution is right here. It's Folders. But it's sometimes tricky. First of all it's kind of a good idea to have one file per class. If you will pack several classes into one file - you'll have problems with finding them with time.
Second thing about folders - if you will click on a folder and choose for example "Add -> New Item", this item will be put into selected folder. But watch out! If you will move files between folders, namespaces are not updated.
It's common source of messing project. Just after a while you can end up with a project where you have neat organized folder and files, but not reflecting namespaces. So for example, if you have class MyClass in folder MyFolder make sure, your namespace for this class is something like MyApp.MyFolder and not some old rubbish.
So If you will not pack classes into one file and watch if classes namespaces reflect folder hierarchy - you're on the good road to make you project very easy to read and navigate.
100% agree with Jon Skeet.
To gain more overview at the folder level we're creating folders breaking the namespace structure by prefixing them with an underscore.