I currently hold my resources in a database instead of resx files. I would like to be able to test whether all keys used in the application are held in the database to avoid runtime errors.
I have a custom ResourceProviderFactory to accomplish retrieving the resources.
Resources could be in aspx view pages - GetLocalResourceObject("ResourceKey") or GetGlobalResourceObject("ResourceClass", "ResourceKey").
They could be in a controller - HttpContext.GetGlobalResourceObject("ResourceClass", "ResourceKey").
I also call the resources from the core assemblies of my application without using the ASP.NET resource factory (using a singleton instead) - CoreResources.Current.GetResource("ResourceClass", "ResourceKey")
What would be the best way for me to ensure that all resources are in the database without having to waiting for a runtime exception?
The only approach I can think of is writing an app that scans your source code files and extracts all the resource keys you are using. You can then check the existence of each key in your database.
Unfortunately it is not so trivial... I don't think there is an easier way.
I would however change your ResourceProviderFactory to not throw an exception in case of a missing key. Just return some text like "Resource missing: 'xxx'" and log it so that it can be added.
Related
I have a web app, using asp.net MVC Core, along with entity framework core. Part of this application has a simple setup table. This is just a table, which will only ever have one record, with a number of fields in, so the administrator can easily change how the web app works.
The setup table is loaded into a static "Settings" class, so anywhere in the application can read it (views and controllers)
What I want to know is when or how is the best place to load this. At the moment I'm loading it in Startup.Configure, after the routes have been set.
For the most part, this works fine. But if I add a field to the setup table, its impossible to migrate (I'm using code first). I get errors about invalid fields. Typically the errors look like this:
An error occurred while calling method 'BuildWebHost' on class 'Program'. Continuing without the application service provider. Error: One or more errors occurred. (Invalid column name 'EmailApiKey'.
Invalid column name 'EmailBaseUrl'.
Invalid column name 'EmailSenderAddress'.
Invalid column name 'EmailSenderDomain'.
Invalid column name 'EmailSenderName'.)
Unable to create an object of type 'ApplicationDbContext'. Add an implementation of 'IDesignTimeDbContextFactory<ApplicationDbContext>' to the project, or see https://go.microsoft.com/fwlink/?linkid=851728 for additional patterns supported at design time.
To get around this, I have to remove the code thats loading the setup table.
This makes me think this is not the best place/way to load settings (seeing as though it obstructs with database migrations).
So - is there a better way to do this? Essentially, I want to:
load a setup table once when app first started.
Have this accessable everywhere in the application (views and controllers).
If a user changes the setup, the static version should be automatically updated.
I would lazy-load the settings on first access rather than at application startup. An advantage is that if the lazy-load fails, you'll just try again next time it's accessed.
If a user changes the setup, the static version should be automatically updated.
You could cache it in the ASP.NET Cache or MemoryCache. You can set an expiration so that it will be refreshed periodically in case a user has made changes. Or if the settings are in a SQL Server database, you can use the SqlCacheDependency class.
LINQ to SQL Connection Strings with class library projects
By default, creating a new LINQ to SQL model (.dbml) will put the
connection strings in both the application settings file and also
web.config / app.config. This is not so much of a problem for web
projects, but what about class library projects? i have a connection
class where I can use it to check connection in all pages but I have an
error where it cant read DataContext at all.
This is a photo that shows my problem.
Generally speaking, class libraries don't support config files. There are ways to make it work, but it's not considered a good practice since different applications may use the same library to interact with different instances of the database. I would recommend looking at a dependency injection or inversion of control solution like Ninject to pass the connection string to the constructor from the app that references the library.
UPDATE:
If you absolutely must read a config file from an assembly instead of the calling application, it can be done with ConfigurationManager.OpenExeConfiguration(). There are several answers here on SO that provide code samples for doing so, but I'm not going to link to them because I strongly encourage you not to go down that road.
By the looks of it you're not using LINQ to SQL - all I can see is an EntityFramework edmx. Check your code generation strategy, and make sure you're trying to instantiate the correct context name (think it's whatever the Entity Container Name is set to).
Also you need to make sure System.Configuration is referenced.
You need to put the connection strings in the main application app.config
Just put a copy of the connection strings in there and you can access them or in this case web.config
Currently in my Asp.Net website I store localization texts in a table in the database. The table has three columns:
TextCode nvarchar(100),
CultureId int,
TextString nvarchar(MAX)
So every time when I need to get a localized text for a specific culture I just do a simple query.
The main advantage of this method is simple and also I can update the texts while my web app is running.
The obvious drawback is performance. I use resource files for localization in other desktop applications. The reason I chose database is I am under an impression that updating the resource file in asp.net will cause the web app to reload and thus I need to take the site offline when I update the resource file. Is assumption true? What's the "common" approach to store localized texts in Asp.Net?
Thanks
Common approach is to use Global and Local resource files. If you want to use database consider using asp.net cache with sql cache dependency. In application start, load all your resource data from sql server and store it in cache, and create a utility class to return data from cache based on resource key.
Folks,
I have an ASP.NET project which is pretty n-tier, by namespace, but I need to separate into three projects: Data Layer, Middle Tier and Front End.
I am doing this because...
A) It seems the right thing to do, and
B) I am having all sorts of problems running unit tests for ASP.NET hosted assemblies.
Anyway, my question is, where do you keep your config info?
Right now, for example, my middle tier classes (which uses Linq to SQL) automatically pull their connection string information from the web.config when instantiating a new data context.
If my data layer is in another project can/should it be using the web.config for configuration info?
If so, how will a unit test, (typically in a separate assembly) provide soch configuration info?
Thank you for your time!
We keep them in a global "Settings" file which happens to be XML. This file contains all the GLOBAL settings, one of which is a connection string pointing to the appropriate server as well as username and password. Then, when my applications consume it, they put the specific catalog (database) they need in the connection string.
We have a version of the file for each operating environment (prod, dev, staging, etc). Then, with two settings -- file path (with a token representing the environment) and the environment -- I can pick up the correct settings files.
This also has the nice benefit of a 30 second failover. Simple change the server name in the settings file and restart the applications (web) and you have failed over (of course you have to restore your data if necessary).
Then when the application starts, we write the correct connection string to the web.config file (if it is different). With this, we can change a website from DEV to PROD by changing one appSettings value.
As long as there isn't too much, it's convenient to have it in the web.config. Of course, your DAL should have absolutely no clue that it comes from there.
A good option is for your data layer to be given its config information when it is called upon to do something, and it will be called upon to do something when a web call comes in. Go ahead and put the information in your web.config. In my current project, I have a static dictionary of connection strings in my data layer, which I fill out like so in a routine called from my global.asax:
CAPPData.ConnectionStrings(DatabaseName.Foo) =
ConfigurationManager.ConnectionStrings("FooConnStr").ConnectionString()
CAPPData.ConnectionStrings(DatabaseName.Bar) =
ConfigurationManager.ConnectionStrings("BarConnStr").ConnectionString()
etc.
"Injecting" it like this can be good for automated testing purposes, depending on how/if you test your DAL. For me, it's just because I didn't want to make a separate configuration file.
For testing purposes don't instantiate DataContext with default ctor. Pass connection string info to constructor.
I prefer to use IoC frameworks to inject connection to data context then inject context to other classes.
I have an ASP.NET MVC application with a separate project added for tests. I know the plusses and minuses of using the connection to the database when running unit tests, and I still want to use it. Yet, every time when I run the tests with the NUnit tool, they all fail due to my Data Context being null. I heard something about having a separate config file for the tests assembly, but i am not sure whether I did it properly, or whether that works at all.
i think you should check this discussion here, it should be related as i was having the same problem.
and how i solve my problem was just to copy my web config content to the app config inside he test project and voila, database connection restore and all is fine in the land of mvc again.
How are you creating your data context? How is it used in your action? Typically, it will use the database referred to when you set up the classes in the designer so you'd get a context connected to what you used for the designer which is, arguably, not what you want for unit tests, thus you add an app.config file to your unit test project and change the connection string to your test database. It doesn't usually result in a null data context.
I suspect that your unit test is simply not touching the code that creates the data context before you invoke the action method. Without code though, it's really impossible to tell.