My project (UI layer is asp.mvc) was developed using .NET 3.5. After upgrading to .NET 4.0 I have got problem with compiled queries:
[ArgumentException: Query was compiled for a different mapping source than the one associated with the specified DataContext.]
System.Data.Linq.CompiledQuery.ExecuteQuery(DataContext context, Object[] args) +863348
System.Data.Linq.CompiledQuery.Invoke(TArg0 arg0, TArg1 arg1) +110
Every time when I run my query I am passing my context
return StaticQueries.getTopFiveOrders(mContext, int howMany);
public static Func<Mycontext, int, IQueryable<Order>> getTopFiveOrders
= CompiledQuery.Compile
((Mycontext mContext, int howMany) =>
( some query).Distinct());
The error occurs on the second request.
This is due to a change in the way compiled queries operate.
They now need to be always run using the same context.
This Microsoft connect page explains why the change was made:
The problem in this case is caused by the fact that CompiledQuery requires the same mapping source to be used for all executions. In the code example you are using to reproduce the problem, the different instances of the DataContext using a new mapping source every time, but the query fails to report this, and just silently fails. If you use the DataContext.Log property or other logging like SQL Server Profiler, you will see that the second UPDATE is not even being sent to the server.
This has been fixed in .NET Framework 4.0 so that an exception is reported that will contain a message like "Query was compiled for a different mapping source than the one associated with the specified DataContext.", and it won't just silently fail. However, the code you provided that is working is the correct way to do this, because it uses the same static mapping source for all instances of LinqTestDataContext.
Basically it was always a problem but used to fail silently, they just made the failure explicit in .NET 4.
I spent a good amount of time looking at this and how the behavior has been changed in .NET 4.0. I've detailed my findings more thoroughly in my blog here:
http://www.roushtech.net/2014/01/19/statically-compiled-linq-queries-broken-in-net-4-0/
The rough of it is: Microsoft made a change to protect people from doing something dumb (reusing a compiled query between different mappings), but appear to have broken a major performance benefit (reusing a compiled query between different contexts of the SAME MAPPING, but different instances of the mapping).
Using getters, or a CompiledQuery that is a member of your class will just result in constant recompilation, and no real performance benefit.
I also faced the similar problem. I removed the static from the compiled queries, it works fine. Although I have yet to find out how much difference it makes on performance.
Related
I've been experimenting with loading functions from the Windows system DLLs using only the loader functions exported by NTDLL. This works as expected. For the sake of curiosity and getting an even better understanding of the process structure in NT-based systems, I've started trying to load functions from NTDLL by doing the following steps:
Load the PEB of the process from gs:[60h]
Iterate over the modules loaded into the process according to the loader to find NTDLL's base address
Parse the PE headers of NTDLL
Try to parse the export table to find LdrLoadDll, LdrGetDllHandle, and LdrGetProcedureAddress
This fails at step 4. After stepping through it in a debugger (both VS2019 and WinDbg Preview), it seems as though the offsets I've tried yield an invalid structure that leads to an access violation when my code compares the current function name to one of the ones I'm searching for. My code is being compiled and run on a 64-bit copy of Windows 10 Pro build 21364. Note that I'm using my own header that contains definitions for the structures used for this (these definitions are from winnt.h and here) because the Windows headers don't really play nice with the rest of my code. The function trying to do this is here. For the record, this is part of an attempt to implement my own libc (again, for the sake of curiosity). The code that calls the functions is here. Any help with this is tremendously appreciated.
Nevermind, turns out I had outdated verbose definitions of the structures I was using. I found better (more up-to-date) definitions at https://vergiliusproject.com.
I am working with a very old vb6 application.
I have made a windows update.
Since this update, i got an exception in my vb6 application:
Float inexact Result occurred in "kernelbase.dll"
I suppose kernelbase.dll now checks invalid float results and i suppose the previous version of kernelbase.dll did not made those tests.
Is there a way to disable those checks in windows kernel ?
I do not have the vb6 application source code...
TL;DR version:
What's the best way to use the .Net Core IConfiguration framework so values in a single appsettings.json file can be used in multiple projects within the solution? Additionally, I need to be able to access the values without using constructor injection (explanation below).
Long version:
To simply things, lets say we have a solution with 3 projects:
Data: responsible for setting up the ApplicationDbContext, generates migrations
Services: class library with some business logic
WebApi: REST API with a Startup.cs
With this architecture, we have to use a work-around for the "add-migration" issue that remains in Core 1.0.0. Part of this work-around means that we have a ApplicationDbContextFactory class that must have a parameterless constructor (no DI) in order for the migration CLI to use it.
Problem: Right now we have connection strings living in two places;
ApplicationDbContextFactory for the migration work-around
in the WebApi's "appsettings.json" file
Prior to .Net Core, we could use ConfigurationManager to pull connection strings for all solution projects from one web.config file based on the startup project. How do we use this new IConfiguration framework to store connection strings in one place that need to be used all over the solution? Additionally, I can't inject into the ApplicationDbContextFactory class' constructor... so that further complicates things (more-so since they changed how the [FromServices] attribute works).
Side note: I would like to avoid implementing an entire DI middleware just to get attribute injection, since Core includes it's own DI framework. If I can avoid that and still access appsettings.json values, that would be ideal.
If I need to add code let me know, this post was already long enough, so I'll hold off on examples until requested. ;)
I'm noticing some odd behaviour when I'm debugging an app written in C++/CX in Release configuration. FYI in case it's relevant I'm using Visual Studio 2013 Community (Update 4).
When I place a breakpoint on a some property getter such as Type1::Label::get() I'm noticing it seems to break when Type2::Label::get() would be invoked but breaks as if the Type1 method was invoked. I'm concerned that there may be something wrong that is causing this problem but I'm perplexed as to why this would only be apparent in Release configuration.
The app appears to otherwise function correctly. Is there a known issue that might explain this problem?
This is probably correct behaviour caused by code optimizations.
If the compiled code for the two get methods is the same then the optimizer will often point both functions at the same location rather than duplicating the code in the final assembly.
Release builds are almost always optimized. Debug builds are almost never optimized.
Optimization makes release builds faster and smaller than debug builds but also much more difficult to debug.
I have a 64bit MFC application, in which I use crash reporting. The method is based on this article:
http://www.codeproject.com/KB/debug/XCrashReportPt1.aspx?display=Print
So I have a __try - __except wrapper frame around AfxWinMain.
Last year it seemed to work well (I mean on different operating systems and also with 32 bit and 64 bit application).
Let's take this exception providing code part:
void CMyDig::Foo()
{
std::vector<int> v;
int i = v.at(42);
}
When I write this code inside a dialog's message-handler, for example a button's clickhandler called Foo, then the exception is not caught in AfxWinMain.
If I write the same to a global function, it passes the exception to AfxWinMain.
Now we have this strange issue:
On some computers the dialog's case also generates the crash report(enters the __except block in afxwinmain), but others no. I managed to create a crash report on win7 64-bit, but the same program on win8, win8.1 and another win7 64bit doesn't make the report!
I compile with vs2010, and in code generation options, the "enable c++ exceptions" is set to EHsc (as last year, when it was working well).
Thanks for any ideas!
Attila
Wouldn't be easier to just define SetUnhandledExceptionFilter to create the crash report.
In this case you don't need such a __try / __except block
WndProcs have their own __try __except blocks and some of the exceptions are handled by themselves.
But anyhow. I never had problems with an exception filter.
My routines usually create a crash dump (minidump) and terminate. I always felt that this bare information is never enough for our technical stuff to find problems.