I have a question about organizing .resx files in mvc3 application. So far I have managed to do the following:
Creating new class library in a solution for resources and adding resources for two languages. Everything works fine when I have for example:
Resources.resx //default language
Resources.en.resx //english language
But I want to have such organization in my class library:
DefaultLanguage foder
- Resources.resx
en folder
- Resources.en.resx
I want to organize resources by folders. I think it is more appropriate for people who will translate the site and it is also more maintainable. When I organize resources in such a way the web page returns an error...cannot find error. Am I missing something? I know that you should not have folder name in namespace because that would mean that referencing resource in View is dependent on folder name and this is not correct.
The point is I would like to have the same behaviour of resources wheter they are organized in folders or not...
By the way: I check on the web and could not find any appropriate solution.
Thank you for your answers!
MVC3 uses ASP.NET resource management. See ASP.NET documentation for details. If you want to rely on ASP.NET behaviour and generated strongly typed classes, then you must keep resource file from default language and other language specific resource files together.
To have the same tree structure that you suggested, then you have to implement your own resource management. You probably don't want to do that, because (at least some) resource editing tools rely on that behaviour.
On our projects we have one resource (and his translations) for each view. They are in folder Localization within MVC3 project. Inside we keep the same tree structure as is within Views folder. This is more or less the same as ASP.NET local resources are organized. Common strings are kept in one .resx file on root of Localization folder. This ensures maintainability.
To keep your people that will do translation happy you have to pick good .resx editing tool.
Related
My ASP.Net Core MVC project consists of 3 website projects, plus associated unit test projects, all collected in a single solution. Each of the website projects relies on common stuff, such as JavaScript libraries (under wwwroot/js/...) and views (under views/...). Is there some feature that lets me package up these files (none of which, as far as I know, can live in a NetStandard library project) and "install" them in all of my website projects so I only need to maintain them in a single place?
A razor class library (RCL) almost does what I want to do, but I want to be able to reference my JavaScript library from views in all three website projects. I also want the bundler/minimizer to be able to find my common JavaScript and CSS files. As far as I can tell, RCL only allows the Razor Pages in the RCL to access the static content (things like my JavaScript and CSS files) in the RCL.
EDIT:
After more thought, I've come to the conclusion that what I'm asking for simply can't be done "out of the box". In order to work correctly, the debugger and the bundler/minimizer need to find js and css files in the project's directory tree. What I'm asking for is a way to have something like a "reference project" that contains these "shared" files. I'm thinking that it's time for the "science project" approach: I'll create a reference project that contains the shared files, and run some code (at build time? via MSBuild? via unit test code?) that updates the files in the project from the reference project if they don't match.
FWIW, here's what I wound up doing:
In my 3 website projects, I have common files in several places:
Views/Shared
wwwroot/js/MyJsLibrary
wwwroot/css/MyCssLibrary
I created a "reference" project that contains copies of the common files in these folders. Then I created a unit test that simply verifies that the files in the "reference" project exist and are identical to files in each of the 3 websites.
No automated magic to keep the folders in sync. If someone changes one of the common files then the unit tests will fail until someone copies the updated file to the website projects and to the "reference" project.
I want to ensure I follow best practices in the context of ASP .NET MVC 3. I am using the Razor template engine to generate automated e-mails when certain actions are performed on an MVC 3 web application.
I have created a separate class library for the e-mailer and this class library will contain the models that will be used when generating the emails as well as a message factory which will generate the necessary message text using the appropriate view and model.
I am unsure as to where I should be storing my view templates. I would like to store them as CSHTML, as this will allow the developers on the project (who are new to Razor) to use IntelliSense while creating the mail templates.
I don't think I can store them in a folder in the class library as this will make deployment more complicated. If I store them in a folder within the MVC 3 Web Application root, they will be accessible to anyone on the internet with knowledge of the correct path. I now consider two options:
Store them in the app_data folder, but this seems untidy.
Store them in a folder called "EmailTemplates" within the Views folder in MVC. I think this is the best option as you can not browse to it directly (no controller) and our developers can access them easily and make use of IntelliSense.
Is option 2 the best option, would it be a sin to have these mail templates located here? I would then access the files directly through the local filesystem but I am not sure if I will have security issues once deployed to production (perhaps using the app_data folder would prevent this). I would like minimal configuration for deployment.
Thanks!
As usual, there's no one right answer, its all about philosophy and approach, but most important (in my mind) - utility. I.E. if it works, easy to maintain, understandable - why not do it?
I would, in your shoes, put it under App_Data folder - this is by definition where all data that application uses goes. Database is there, configuration XMLs are there etc. So why not use that folder for your purpose.
You can easily access it like this from within your C# code: System.Web.HttpContext.Current.Server.MapPath(#"~/App_Data"). I don't think any other (created by yourself) folder will be any better or worse ... its just App_Data is there specifically for these purposes, but it doesn't mean you cannot do something else, that makes sense in your application.
Hope this helps.
After doing more research and some experimenting, the Views folder seems to be the best place for my email templates. Here's my reasoning:
The email templates will only be used by the web application and nothing else.
The application pool the MVC application will run under, will at the very least have access to read the folders within the Views folder. This means I don't need to cater for any special permissions for folders during deployment. (Although this is true of the App_Data folder as well).
IntelliSense does not work from within the App_Data folder but does work within the Views folder. As the developers on this project are new to Razor, IntelliSense will make things easier for them. Also just makes development of the templates easier.
Although I created a separate project for the template mailer, one
can store the models for the mail templates with your MVC models as
well.
In ASP.NET Webform, App_Code is the standard folder for putting code and using it at run-time. But I think this folder is kind of different in ASP.NET MVC, my question is:
where should I put my code ( Extension methods, Helpers, ... ) in ASP.NET MVC. When I store code in App_Code folder, I can't use them in controller but they work fine in views.
About Entity Framework, the same question, where should I put edmx and tt files? I'm not using Code-First
Update:
After some search, finally I created a new Class Library project in my solution, code is available in all controllers and views. I still don't know why the code in App_Code is not available in the controller
I had the same issue, my class Utility.cs was not recognized inside my MVC project. I changed the Build Action "Content" to "Compile" and that solved my problem.
Hope that helps.
App_Code is necessary in Web Site projects because it has a special meaning. It means "Don't serve these files to a web browser". In ASP.NET MVC, files are not directly served to the browser in most cases, so App_Code is not necessary. You can place code files whereever you want, in any folder you want because these files are compiled into a DLL and not typically published to the website itself.
Using a stand-alone library is also a fine solution.
No one really explains why App_Code exists in the first place. It's the place where you put code files to get dynamic compilation (at runtime). That's the number one reason for App_Code and why it is special. You can put code in any folder you want but you will have to mark it with Compile action to compile while in App_Code that is not necessary, in fact, most files in App_Code aren't even a part of a project.
It does work in ASP.NET MVC projects too you just have to name your code files with .cshtml extension.
I'd recommend starting with this tutorial. It uses EF code first, but you can simply replace the code first DbContext with a normal edmx ObjectContext if you wish (hint: Models folder).
App_Code is specific to Web Site Projects. IMO, its a terrible way to organize all but the simplest of web sites. An MVC project is a Web Application Project, so there is no App_Code and your classes can be defined pretty much anywhere.
Well, try to download some already existing opensource projects. One of them is rather complex, but very cool if you'll get understanding of it - orchard
The best practice is moving this logic to DAL (data access layer) or BLL(business logics layers). Depends on complexity of your application.
For those who don’t want a second project/class library and just want a simple folder for a few c# classes, I propose “App_Classes”.
I need to rebrand my application, that means create another application resource file with different strings, slash screen and icons.
My application is also localized for a second language, i have another resource file with all application string which is translated, that creates me additional, satellite dll.
I need to build 4 setup project 2 for each language and 2 for each brand name.
What will the elegant solution for this? Is there any way to create additional application resource file same way I did with language translation and how I include a satellite (resource in a second language dll) in my setup project and not including resources in the original, neutral language.
Thank you.
I assume that those branding resources are not in setup project, but in main project, and that main project is C++.
In C++ you can have several .rc files in a project. This is most likely true for C# resources too. Move all branding material to second resource file. Create another project, shallow in nature, that references all files (including .rc) from original, but uses its own versions of branding files. Apart from strings, icons, and images maybe you will have some dialogs copied and branded as well. Make sure they all have resource identifiers in sync.
Creating another project can be done by just copying original project and fiddling with paths in text editor. Just make sure you change the project GUID, so that two project can coexist in the same solution.
Examples given are from Kohana 3, but the question is not limited to the framework.
I've always put my assets in a file structure like this
application
- classes
- views
assets
- css
- js
- swf
- images
-- layout
-- content
system
- classes
I've started reading a few forums where people always mention their assets files are placed in the views folder. This makes a lot of sense to me as these files are tied to the views quite closely (being included by markup). Plus, it will unclutter the docroot.
What is the preferred location of a site's assets? If I do place them under an views/assets folder, where should the actual template files go... under a separate folder like views/templates ?
For ASP.NET MVC
The project template gives you the folders ~\Content and ~\Scripts with the latter containing JQuery.
Why not follow this model, adding additional folders below these if they would otherwise get too many items.
I would stick to the project template unless there is a very good reason to override it (and also override the logic to find views and controllers).
I tend to place mine in the web root (wherever that's defined by the framework) so that I can reference /assets/img/myimage.jpg (or an analogous CSS/JS file, etc.). As Richard suggests, though, I do this because I'm sticking to the framework convention. I'm not familiar with Kohana, but the frameworks I've used extensively all place assets in the web root by convention.