I have a multi project solution for an asp.net website. There is DAL, BLL and entity projects all shared with another application and a resources project for strings (to support multiple languages).
The resource is set to public. Common.Resources is the both the project name and the namespace. Strings is the Resource file. Accessing the resources in code after referencing the project is easy
Common.Resources.Strings.[MyResourceStringNameHere]
The issue is I need to access the resource strings in the sitemap and in literal html tags doesn't work. Examples of what i have tried below.
$Resources:Strings, [MyResourceStringNameHere]
$Resources:Common.Resources.Strings, [MyResourceStringNameHere]
Much searching has led me to believe that I may need a resource manager to bring in the resources from the other project. All examples are aimed towards a SQL resource manager so aren't proving particularly helpful.
Any examples, suggestions, etc would be gratefully received.
Thanks in advance...
Here's nice example of sitemap globalization for ASP.NET Core using external resources:
Globalization in MVCSiteMapProvider
If project does not use ASP .NET Core, you can follow instructions in: https://msdn.microsoft.com/en-us/library/aa905797.aspx#exaspnet20rpm_topic5
Basically, you need to create custom ResourceProviderFactory which should return yours implementation of IResourceProvider where you can handle external resources.
Related
I am pretty new to mvc but have already read a few books.
What I want to archive is:
-> Having the main asp.net app in its own project.
-> Every modul (for example forum modul) is hosted in a regular dll (including its controller, models and views).
I've looked into the issue of hosting controllers in different assemblies. This is actually easy to handle. But what I do have issues with are the views.
I could not find any resource regarding how to tell mvc that he should look for the views in this namespace the the other view in the other namespace.
Best regards
Simon
Have you imported the projects/assemblies in the project you need to use them?
Look in the References folder. They must be there so you can use them.
I am not quite clear why you would use this style of architecture, but again that's your choice.
What I can confirm is that it is not going to be as useful as you think.
A detailed explanation is here
tl;dr Does strongly typed resource code generation work with normal (non-embedded) resources in App_LocalResources?
If not then why, and does the alternative of using embedded resources in satellite assemblies work with implicit localization?
The rest of this post just explains where I currently am in solving these questions, feel free to ignore it if you know the answers.
When using implicit localization (meta:resourceKey="Foo" syntax), I understand that one would need to write their own resource provider if one wants to embed the resources in satellite assemblies. The reason would be that ASP.NET always uses the default provider for these, and that this provider expects resx files in App_LocalResources that can be retrieved at runtime. Also see this question, which has no answer at the time of this writing.
If that assumption is correct, then it doesn't seem possible to use strongly typed generated classes (using ResXFileCodeGenerator) without writing such a provider (which we'd like to avoid doing), as enabling code generation requires the use of embedded resources.
Because the use of generated types appears to work perfectly fine for global resources, I want to question that second assumption:
If I can generate strongly typed classes for global resources (in App_GlobalResources using GlobalResourceProxyGenerator) without embedding them in a satellite assembly (Build Action set to Content as opposed to Embedded), then why can't I do the same for local resources? Why can't the generated code find and use the resx files in App_LocalResources?
Note that the exception thrown when attempting to do this is a System.Resources.MissingManifestResourceException containing the following message:
Could not find any resources appropriate for the specified culture or
the neutral culture. Make sure
"PROJECT.App_LocalResources.PAGE.aspx.resources" was
correctly embedded or linked into assembly "PROJECT" at
compile time, or that all the satellite assemblies required are
loadable and fully signed.
I know that this message is misleading, as it clearly looks up satellite assemblies instead of trying the resx files (or whatever they're compiled to by the runtime, App_LocalResources.dll I guess).
If there is a good reason why this is not allowed (and we are thus forced to use embedded resources in satellite assemblies), is there a good implementation of a resource provider that can look up resources in satellite assemblies when doing implicit localization? Surely somebody has tried to do this before, and it doesn't sound like the application developer's job to tackle this kind of plumbing problem.
As a sub-question to the previous one, I also assume that when using embedded resources in satellite assemblies, one wouldn't put the resx files in the App_* directories, as these are special directories used by the runtime. Indeed, the resx files aren't even deployed, so the directories would be empty. Is that correct, and are there what would pass as best practices regarding this?
I suppose another way of formulating the question is: Can I make ResXFileCodeGenerator behave like GlobalResourceProxyGenerator when it comes to generating code that can load assemblies compiled by the runtime, as opposed to satellite assemblies compiled at build time?
Embedded resources can co-exist with ASP.NET Resource provider resources that live in the App_LocalResources/App_GlobalResources folder. But all the intrinsic WebForms localization features only work with the resources that are fed by the ASP.NET Resource Provider, which means the resources by default come out of the App_ folders only - not from embedded resources.
Embedded strongly typed resources do not use the ASP.NET Resource Provider - they use a stock .NET Resource Manager and when you use them you lose some of the optimizations that the ASP.NET ResourceProvider system uses vis a vis caching and loading of resources. It's more efficient in the ASP.NET scenario.
As you correctly point out it's possible to do this by creating a custom resource provider that reads embedded resources (or resources from another source such as a database), but you have to create this resource provider and hook it up. I wrote about this in an article some time ago (using a SQL database provider): http://www.west-wind.com/presentations/wwDbResourceProvider/
I wouldn't recommend mixing App_ folder resources from the Resource Provider with strongly typed resources because you'll end up with two different sets of resources loaded using different mechanisms. It works and can be done but it's just not very inconsistent. Pick one approach or the other. For Web Forms the resource provider model works better simply because it's the only way you'll be able to use implicit resources.
Note that ASP.NET MVC doesn't use the ASP.NET Resource Provider typically (although it could) and rather relies on strongly typed resources embedded into the code. If your WebForms code is mainly script based then using embedded resources might work well, but if you need to bind control properties the Resource Provider is the only way to go.
I have a web service and a client. The classes used in parameters and return types are in a common DLL shared by both. However, whenever I update the web reference, visual studio generates copies of the classes with the same names and public properties and methods. Then the solution won't compile because the client code tries to use the versions in the common DLL. I can solve the problem by deleting the "duplicate" classes every time I update the web reference, and adding a using statement to point at the common dll's namespace. Is there a way to fix this permanently?
UPDATE: See my comments below. This is a "feature" of asmx web services. There is no way around it other than one of the following:
1) Use a more modern type of web service.
2) Don't use a common DLL
3) Manually fix every time you update the web reference, as in the original question above.
This is a "feature" of asmx web services. There is no way around it other than one of the
following:
Use a more modern type of web service.
Don't use a common DLL
Manually fix every time you update the web reference, as in the original question above.
Sources: Other stackoverflow questions:
"Reuse existing types" is ignored when adding a service reference
How does Visual Studio 2008 and svcutil decide which types to re-use from referenced assemblies when generating a web service proxy class?
I had the same problem, but I had neglected to add the reference the correct assembly with the request/response types in my client. Once I added that reference, and ensured that the "Reuse types" checkbox was on in the Add Service Reference dialog, it worked properly.
There`s no way to do that.
However, I think we have a design problem here. When we create a web service, we expect that our clients don't need to reference any dll from us. Only the types exposed by the web service should be enough for their use (web services are all about interoperability, imagine your client app written in Java, you can't reference the .NET dll).
That's why these types are created when you reference a web service. In my opinion, you should only rely on the classes generated by the web service in your client app. Remove the reference to the shared dll from the client project.
This doesn't direct answer your question, but provides an alternative for your issue.
In the domain class, set AnonymousType=false to prevent generating class with prefix unexpected when adding the web reference
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType = false)]
but this only ensure that the class, auto-gen in Reference.cs has the same structure as the domain class.
A way to walk aroud this is to serialize/deserialize to the domain object.
I created an empty Visual Studio solution and added two projects: Backend(Class Library type) that will have the.edmx file for accessing information; and Frontend(ASP.Net type) that will have the database in the app_data folder.
Is this a good architectural design or is there a more proven way to organize this type of application?
Splitting the data access code into a library project is a good idea. I'm currently working on an ASP.NET project which is almost the same - I have a library class that I use to access the data, and in the other project I have my aspx pages. The only difference is that my data is in SQL Server (using entity framework to access that data via a .DBML file).
For the type of site you're building (data in the App_Data folder) it sounds like it will be a simple site which does not need to do anything too intense i.e. scaling.
Most often it depends on the size of your project, but generally I tend to separate the front-end stuff from the backend s.t. it gets reusable. So to that direction your organization is already fine.
If you want to go a step further, I'd take a look at layered application architectures. This post here may give you some insight into that and you may find some reusable elements.
Personally I don't really like the DB to reside in the "app_data" folder of the UI project (i.e. the ASP.net Web Application project). But for small apps it's fine :)
Are there solutions/tutorials/open source solutions to providing the functionality of having Content Editors edit ASP.net Localization files?
For example,
With Labels.resx and Labels.fr.resx, it would be great if theres an editor out there that allows End Users to end the content of the file.
I would suggest a database solution with caching. I found this article which might help. It has a complete provider along with a very good write up.
Creating a Data Driven ASP.NET Localization
Resource Provider and Editor
http://www.west-wind.com/presentations/wwDbResourceProvider/
ASP.NET 2.0 introduces a provider
model for creating custom Resource
Providers that can store localization
data in stores other than Resx files.
Resx resources are all fine and good
but putting data in a more flexible
resource store gives you many more
options for editing and administering
resources interactively and even at
runtime. In this article I'll
demonstrate how to create a new
Resource Provider that stores resource
information in a database and show a
resource editing tool that makes it
much easier to edit resources
interactively in the context of your
live ASP.NET applications.
Particular bit to note:
Resx Resources are also static – they
are after all compiled into an
assembly. If you want to make changes
to resources you will need to
recompile to see those changes.
ASP.NET 2.0 introduces Global and
Local Resources which can be stored on
the server and can be updated
dynamically – the ASP.NET compiler can
actually compile them at runtime.
However, if you use a precompiled Web
deployment model the resources still
end up being static and cannot be
changed at runtime. So once you’re
done with compilation the resources
are fixed.
I just wrote an application like that because I could not find a free soft that does resx editing:
Reads the content of all the resx files from a folder
Displays the values from different cultures but same resx besides each other
Generates/saves the resx files back
You might consider using structured XML files. Seems like this would be a more elegant solution than hacking .resx files to work in an unconventional way. You could use a LINQ query to get to the XML in a strongly typed manner similar to the resx file. Additionally, XML files could be edited by the user through the presentation layer since they aren't compiled into the application.