I have an asp.net mvc application, which uses the default user database. It all works pretty well, but I would like to create some tests for it. I Have a test project, I immediately stumble upon an exception
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
But the connection string is working perfectly (at least in the mvc project's web.config). The exception is thrown by my Entity DB access logic constructor
public ASPNETDBEntities() :
base("name=ASPNETDBEntities", "ASPNETDBEntities")
{
this.OnContextCreated();
}
Any ideas?
Thanks in advance.
The problem is that when running the unit tests, you need to have a connection string set in the App.config file of the test project in order for Entity Framework to find it.
However, if you're doing unit testing you most likely don't want to access the db at all, but rather mock up some dummy objects to test against. (If this is hard to do in your code as it is, you might need some refactoring of your code...)
A third possible scenario is that you're doing integration testing, and thus want to access a real db when testing - however, it doesn't have to be the real db. It can be any db with the same database schema. I'd recommend setting up a dummy db with some dummy records in it, which you can perform tests against (and which you put a connectionstring for in the App.config file in the test project) that will not grow and become slower when the "real" db does.
Related
I building multitenancy into the unit of work for a set of services. I want to keep the tenancy question out of the way of day-to-day business domain work, and I do not want to touch every existing consumer in the system (I am retrofitting the multitenancy onto a system without any prior concept of a tenant).
Most messages in the system will be contexted by a tenant. However, there will be some infrastructure messages which will not be, particularly for the purpose of automating tenant creation. I need a way of determining whether to use a tenant-contexted unit of work, or a infrastructure unit of work uncontexted by a tenant because the way I interact with the database is different depending on whether I have tenant context. The unit of work is built in the process of spinning up the dependencies of the consumer.
As such I need a way of peeking at the message or its metadata before consuming it, and specifically, I need to be able to peek at it during the dependency building. I was intended to have a tag interface to mark tenant management messages out from normal business domain messages, but any form of identifying the difference could work. If I am in a unit of work resulting from an HTTP request, I can look at WebApi's HttpContext.Current and see the headers of the current request, etc. How do I do something analogous to this if I am in a unit of work resulting from messaging?
I see there is a way to intercept messages with BeforeConsumingMessage() but I need a way of correlating it to the current unit of work I am spinning up and I'm not seeing how that would work for me. Pseudocode for what I am trying to do:
if MessageContext.Message.GetType() = typeof<ITenantInfrastructureMessage>:
database = new Database(...)
else:
tenantId = MessageContext.Headers.TenantId;
database = new TenantDatabase(..., tenantId)
I am working in C#/.NET using MassTransit with RabbitMQ and Autofac with MassTransit's built-in support for both.
Your best option is to override at the IConsumerFactory<T> extension point, and extract the tenant from the message (either via a message header, or some message property) and register that in the container child lifetime scope so that subsequent resolutions from the actual consumer class (and it's dependencies) are properly matched to the tenant in the message.
In our systems, we have a TenantContext that is registered in a newly created LifetimeScope (we're using Autofac), after which we resolve the consume from the child scope, and the dependencies that use the tenant context get the proper value since it's registered as part of building the child container for the message scope.
It works extremely well, we even built up extension methods to make it easy for developers registering consumers to specify "tenant context providers" that go from a message type to the proper tenant id, which is used to build the TenantContext.
You can do similar things with activity factories in Courier routing slips (which are a specialization of a consumer).
I have a ASP.NET Web application. The application connects three different databases. So I have defined three connection string in web.config with different database name and credentials.From the application code I am pointing to the relevant connection string and firing stored procedures. Sometimes the procedures are hitting the wrong database. My guess is that as .NET cache the web.config, somehow the framework is returning the wrong connection string from cache and the application hitting the wrong database. I have checked the application code and found it is pointing to the correct connection database in all cases. Is this happening due to web.config chancing? I cannot identify the root cause of the problem. Please help.
If you are using EF to connect to the database, you have to close the scope of the context and then initialize a new context with the required connection string and then use that context to execute the SP.
I don't think this is an issue with the caching !
If there is only one DAL which connecting to different databases then it is a high chance of application mistake somewhere.
Possible solution, as we have no idea of how is you data access code looks like, is to create 3 different DAL and in each of them realize logic to work only with specified connection string.
For example create 3 different classes inherited from DbContext with different connection strings in constructors.
Hi I am working on ASP.NET MVC project. Currently I am using Model first approach, where i used to add database manually by using ADO.NET model. Currently I have 4 database and I have 4 connection strings in web.config file.
It was fine till now, since I was working on development environment. But now I need to move my code to live and problem is, in live we have like 40 to 50 databases.
So what I should do is, generate connection string dynamically when user wants to connect to particular database.
I have stored procedure for this which returns connection string and database name.
For example if I have 4 database name like db1, db2, db3 and db4, I need to compare this database name with my stored procedure results database name and if both are equal, then generate connection string equal to that database name.
And also I need to put this in session once i generate connection string, so no need to generate connection string again for particular session.
Can someone help me in this??
EF DbContext as a constructor parameter takes a name of a connection string or connection string itself. So there is no problem in generating any kind of connection string and supply this when creating DdContext.
In our application we have many tenants and have a database per tenant. For every request we lookup what tenant it is and from Settings DB provide a connection string to tenant's own database.
I've not worked with Ado.Net, but from what I see in Google, this is very similar (or based on) to Entity Framework. So down to your particular implementation, there must be a way to provide connection string to database context outwith web.config.
Currently I've got a couple of files in my view that I'm now beginning to design visually (through CSS) by vising the local web app in my browser. To get to these views, you have to go through an authentication step in my application.
Now when testing the authentication step in a controller, I use a fixture containing some test login credentials. This allows me test other parts of the application after this step. However if I wanted to test using the server, I would have to use real credetials from the database. Am I supposed to put fake data in the 'development' database so I can do this, and instead use real data in the 'production' database?
What you're trying to achieve is called integration testing (or end-to-end testing). Rails provides integration testing out of the box.
Personal preferences : I use Cucumber with the Capybara DSL, and seed data corresponding to my features/scenarios using Cucumber's hooks.
EDIT : at first read, I didn't understand that by "testing" you meant "manual testing". In this case yes, you'd better seed your development database with fake data corresponding to your features/test cases.
I have one type provider that connects to the network to retrieve data.
And produce (the fiction we call) 'static type' through type providers mechanism.
Of course, I might not always be connected. I might be raging in a private jet with satellite connection down.
Has anyone experience building an "offline type provider" which take (somehow) a type (from a type provider) as an input, stores its definition on disk, and provides you later with said type definition for easy access while on your way to Koh Phangan ?
Since types are not allowed as parameter to TP, I was thinking in providing assembly name + type name to be offlined.
You can enhance your original type provider to work both in online and offline modes. I.e. provider tries to connect to data source and fetch schema, if successful schema is cached on disk (in some format that provider can understand). After that provider exposes types using schema information on disk. If for some reason connection to data source is not available - provider checks if cached schema exists and if yes - uses it. For example standard type providers (LINQ2SQL or EF) allow you to specify schema file that can be used if direct connection to database is not possible.
This is a tricky aspect of writing F# type providers. But I think the main problem is that when you're developing in a private jet and you're using type providers to access some external data source, then you won't be able to access the data.
Schema caching -
If the type provider supports some form of schema caching (i.e. by storing the schema in a XML file like LINQ to SQL mentioned by #desco), then you'll be able to write some code and compile it, but you still won't be able to test the code. I think this makes schema caching less useful for the private-jet scenario. However, it is useful in scenario where you build code on a build server that does not have access to the schema.
Local data - For the private-jet scenario, you probably need some sort of local data (or a subset), to be actually able to test the code you write and then you can often point the type provider to your local copy (database, CSV or XML file etc.).
Meta-provider - I think the idea of having meta-provider is pretty cool - it should work to some extent - you would be able to cache the schema, but you probably wouldn't be able to cache the data (perhaps the values of properites, but I guess methods would not work). I think it should be possible to just pass the name of the provider to mock as an argument to your meta-provider. Something like:
type CachedDB =
SchemaCachingProvider<"FSharp.Data.TypeProviders.dll", "SqlDataConnection", "..">
I'm not aware of any plans for doing something like this, but if you started, I'm sure the FSharpX people would be interested in looking at it :-).