What's your opinion for the best possible way to build asp.net multilingual localized web application (only UI localization of string resources). Especially this two things:
How to store resources? Xml files, resx files or something else?
How to handle URL's? I don't want to keep language parameter in query string all the time so I need to use URL rewriting maybe?
/BR
Have you looked into the localization support in ASP.NET? It uses resource assemblies and sets the default resource based on the browser's settings. You can also override the setting by setting the culture and uiculture settings for the thread handling the request.
If you don't like using the resource assemblies (which do require a project rebuild when you want to make changes), you can also create a custom resource provider for ASP.NET (this link uses MS Access as an example, you can try to customize it for SQL or some other provider).
http://asp.net has some tutorials to get you started, like this one.
Use Data Driven ASP.NET Localization Resource Provider as described in http://www.west-wind.com/presentations/wwdbresourceprovider/
Related
I have a client that's converting from a PHP system to a .NET system. One requirement is that certain legacy system URLs ending in ".php" are still accessible in the new .NET environment.
Essentially I need to map arbitrary string paths to specific Controllers/Actions.
Can anyone tell me what the recommended and most performant approach is in ASP.NET Core 2.0 to handle this scenario? Custom middleware? Introduce a Web.Config? Action attributes in the controller?
Are there any "gotchas" I should be on the lookout for?
The site is hosted in Azure, if that makes a difference.
Thanks in advance!
Can anyone tell me what the recommended and most performant approach is in ASP.NET Core 2.0 to handle this scenario? Custom middleware? Introduce a Web.Config? Action attributes in the controller?
I assume that you could leverage URL Rewrite and read the related tutorials. I just checked it and added the URL rewrite rule under my azure web app via the Azure App Service Editor as follows:
TEST:
Additionally, you could also write the URL rewrite rules in your code, details you could follow URL Rewriting Middleware in ASP.NET Core.
Lately my focus has been on creating an ASP.NET MVC application that can host 3rd party MVC plugins. Ideally, development of those plugins would follow these rules:
Plugins can be developed in a standard MVC project, and be able to use all the existing infrastructure of the ASP.NET MVC framework.
The complexity of compiling the plugin MVC project and including into a host MVC application should not be severe.
Any changes to the normal development flow of an MVC application would be the bear minimum
After some research I've come up with the following approaches to achieve this, each with their own advantages and disadvantages.
Approach 1 - MVC plugin assembly loaded into main MVC AppDomain
Work Flow
Develop plugin inside a separate MVC project.
Compile the assembly and load it and any dependencies into the host application via PreApplicationStartMethodAttribute, MEF or a basic assembly reference within the host project (if possible).
Map a route to the plugin controllers so that the plugin is treated as an Area within the host.
Place the plugin views into the correct area folder. The layout file will need to be changed so that the layout path points to an area based location, rather than the root of the application (which would have been the case in the development MVC project)
When a request comes in for the plugin, ASP.NET will use the existing areas functionality to route the request to the correct controllers and look in the correct location for the view files.
Advantages
Will work as seamlessly as if the controllers were embedded in the host MVC application assembly.
Simple to include the assemblies into the host App Domain before application start (PreApplicationStartMethodAttribute, project reference) and after application start (MEF)
Disadvantages
No sandboxing - the controllers will have the same trust level as host.
Conclusion
This is the easiest approach, however it is also the least secure. It essentially removes the possibility of allowing untrusted developers to create plugins because those plugins will have the same trust level as the host application (meaning that if the host application can execute methods such as System.IO.File.Delete, so can the plugin)
Approach 2 - MVC plugin assembly running in own AppDomain via MAF
This approach intends to allow the creation of MVC plugins that can be sandboxed into their own AppDomains and used by the host via the System.Addin libraries.
Structure
A route is setup in the host that determines whether the url being processed is targeting a plugin. May have a pattern such as example.com/p/{plugin}/{controller}/{action}/{id}
All routes that have the above pattern are mapped to a host controller that has a module routing action. That action looks at any given route and determines the appropriate plugin to process the request based on the {plugin} segment.
The plugin view is a receiver/sender object that acts as a gateway to the plugin controllers. It has a method called AcceptRequest that receives a RequestContext from the host, and that returns an ActionResult.
The plugin pipeline contains adapters that can serialise RequestContext and ActionResult for transmission across the isolation boundary of the pipeline.
Execution Flow
A route for a plugin is matched and the plugin routing controller is called.
The controller loads the required plugin into it's own AppDomain and calls AcceptRequest, passing through the RequestContext (which is serialised via the pipeline)
AcceptRequest receives the context and determines the appropriate controller to execute based on that request (using a custom controller factory).
Once the controller has finished executing the request, it returns an ActionResult to the receiver object which then passed that ActionResult (also serialised via the pipeline) back to the host AppDomain.
The controller that initially called AcceptRequest can then return the ActionResult to the host MVC execution pipeline, as if it processed the request itself. The plugin AppDomain can then be unloaded if so wished.
Advantages
Plugin will be sandboxed in it's AppDomain, thus any permission set can be used that suits the host.
Disadvantages
Would have to be possible to serialise RequestContext and ActionResult.
Will possibly break other ASP.NET MVC functionality within the isolated AppDomain.
Conclusion
This approach sounds good on paper, but I'm not sure if it's possible/feasible to serialise the RequestContext and ActionResult objects, as well as run an MVC controller in isolation.
Questions
The first approach is fine if the code is being created by trusted developers. I know that I'm not going delete all the host view files or it's web.config file. But ultimately, if you want third party devs to create plugins for your MVC app, you need to be able to sandbox their code.
From all my research, the System.Addin library makes it easy to implement a host/plugin environment when you are using simple API based class libraries. However it seems that it isn't easy to do this when MVC is involved.
Some questions I have are:
Is the second approach I've outlined here feasible?
Is there a better way to do this?
Is there going to be easier ways to achieve MVC plugin isolation in the future?
You're going to end up making separate sites for each plugin. This way you can create reduced-privilege users for each AppPool and a systems administrator can install the "plugin" as a website running under that user.
Any alternatives are going to exhibit the Inner Platform antipattern. Unless you have a lot of time and money to spend developing a plugin-hosting system, you're going to become mired in it and resent it. I speak from experience.
The sites can share AspnetIdentity user repos and you can provide your core objects as a dll that can be referenced. Host your content (script files, css, images) on a CDN so they can be referenced. If you want to share views with your child sites, compile them in as resources:
Including Pre-Compiled Views in an ASP.NET MVC Web Application
Good luck!
IMHO System.AddIn is a a bit overkill for what you are trying to do.
Are you familiar with the System.Security.Permissions namespace? If not you could have a look at the FileIOPermission. Perhaps you could sandbox your extensible system by using (and why not, even extending) the Code Access Security mechanism of .NET.
I have added a resource file in App_GlobalResources called FileList.resx.
Now I access the contents within the code by using
My.Resources.FileList.astro1 etc.
It works fine if I set the Build Action of resource file to Embedded. However in this case the resource file is not available after compile and I can't change it later.
If I set the Build Action to Content I get an error : Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "WAP.FileList.resources" was correctly embedded or linked into assembly "WAP" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Please advice me.
Are you using a Visual Studio Web Application? Or a Web Site?
In the latter case, you should be able to change the Resource file after deploying the site, and it should get automatically recompiled on the server. In the former case, it's a built-in that can't be changed after the site is compiled before deployment.
If that's a problem for you, there are of course alternatives to Resource files....
In any way of compiling and deploying your application all resource files will compiled in related to each resource file assemblies. In all cases, resource assemblies are ultimately created for each directory in the site, and satellite assemblies are generated beneath their respective culture-specific directories. Even when the site is JIT-compiled, the outcome is equivalent.
So, you must use Build Action of resource file to Embedded, but as possible solution for dynamic resource definition you can place you resources in a database. And even provide a Resource provider. In that case your database solution would have all the benefits that suggested by resource management aka dynamic culture definition, using resource binding to control, etc.
Here you can find some tutorials how to implement Resource-Provider Model in your application:
Extending the ASP.NET 2.0 Resource-Provider Model
Creating a Data Driven ASP.NET Localization
Resource Provider and Editor
Currently we have a bunch of web sites (web site projects) that I think should be converted to web application projects. Everybody agrees.
But a number of custom BuildProviders are used to generate controls and unfortunately MSDN says that
Adding a customized BuildProvider class to the Web.config file works in an ASP.NET Web site but does not work in an ASP.NET Web application project
Are there some ways to migrate though without full discarding of custom BuildProviders mechanism?
Without knowing exactly what your build provider do I can see two possible solutions:
Custom MSBuild tasks
T4 templates
Hey you need to implement, a custom IVsSingleFileGenerator.
And register it with your VS, to generate a custom .designer-File.
The way DesignTime-Compilation works changed with Web Application Projects.
In combination with a BuildProvider you will get the same as ASPX-Pages.
I used it to generate user-interfaces with partial-methods to implement behavior in a codebehind-file.
That's impossible without review of the whole approach.
I have a component (an assembly built in .net) that i need to access on (almost) every request to two different websites. One website is written in classic asp and the other one in asp.net mvc.
At the moment i reference the assembly in the asp.net solution and call it like i would any .net assembly. On the classic asp website, i call it through a COM wrapper.
This is all good, except now i need this component to actually stay alive and monitor changes to a configuration file. In my asp.net website i could keep a refence in the application scope and i guess i could register it in component services for the asp access.
Is this the best way to do it? Also, this way the component would actually be hosted twice - one instance in the asp.net application scope and one in the component services. I could perhaps instead only have it live in component services, and then instead reference it from asp.net.
I don't know - something smells fishy (and no, it's not me) - am i on the right track or do you see better alternatives?
Do you really need a long running object? You say you need to monitor configuration file changes -- when the config changes do you need to trigger some actions or do you just need to ensure that each incoming request uses the latest copy of the configuration for your component? If it is the latter then standard .NET configuration should work for you without concern for the object lifetime.
In terms of hosting, do you need to use any COM+ services? If not, then I would not use COM+. If you want one central location for your .NET component, why not register it in the GAC?
Ok so i think i found two solutions, both acceptable for this project:
1) Register it in global.asa on the Application_OnStart in the Application object like this Application("Someobject") = Server.CreateObject("Someobject")
2) Host it in component services and handle lifetime there.