Entity Framework Exception on Windows 2019 when using MSDTC - entity-framework

We have 2 servers. One box is a MS SQL Server 2017 (14.0.3192.2) running on Windows Server 2016. The other is a Windows Server 2019 box running a web service with EF 6.2.0. The 2019 box is new, the production web service is running on a Win 2k12 R2 server currently with no issues. When EF needs to perform multiple transactions in a call it sounds like the call is promoted to use MS Distributed Transaction Coordinator. On the new 2019 server we are seeing these requests as being aborted. The exception we are seeing thrown in code is "The operation is not valid for the current state of the enlistment". I've run through all the DTC troubleshooting, but everything seems to check out. We don't use the Windows Firewall and no firewall is between the servers. The Local DTC config matches our existing server and the dtcping.exe tool reports no issues talking between servers. If we turn off the code that is causing multiple transactions then the issue goes away so everything is pointing to an issue between EF and MSDTC.
We haven't been able to get the multiple transactions working on our development computers either (Windows 10). Is it possible something broke with EF and DTC in more recent versions of windows or are we missing something?
I asked in the EF github project and was told this may be more for the sql-client team than EF. I tagged sqlclient as well on this.

We attempted to pull down the Entity Framework 6.3.0 preview 9 nuget package and tested it on the new Windows 2019 servers and magically DTC works (doesn't abort) with the Scoped Transactions. Something in the 6.3.0 build of EF must fix the issue we are experiencing with our DTC transactions aborting using the EF 6.2.0 public nuget build.
Since the 6.3.0 is still in preview we have rolled back to 6.2.0 in the meantime and turned off our scoped transactions until 6.3.0 is in full release. I'll update the github issue regarding this so the development team is aware.

Related

Microsoft Dynamics CRM - Plugin Running in Context of .NET 4.0

I wrote a plugin for Microsoft Dynamics CRM 2011. It runs alongside a bunch of other plugins written by different contractors targeting different versions of .NET.
My plugin targets .NET 4.5. I recently installed .NET 4.5 on the CRM web servers. If a user causes my plugin to fire (Create/Update of account), the plugin runs fine without any issues.
However, when an updates comes from a different plugin, the following error is thrown:
Method not found: 'System.Delegate System.Reflection.MethodInfo.CreateDelegate(System.Type)'
The limited stack trace we've received from the contractor reporting the error says it's occurring within my plugin. I am using Ninject, which I think is the likely culprit. I am guessing that somehow my plugin is being run in a .NET 4.0 environment where this method does not exist.
I am not very familiar with the way CRM runs plugins. Outside of the web servers, do I need to install .NET 4.5 on any other machines? Could this be related to a .NET 4.0 plugin indirectly calling my .NET 4.5 plugin?
Even for crm-2013 Microsoft says that you should use .net 4.0. I think that you are right on the mark when you say that it's the interaction between 4.0 and 4.5 in your plugin. Can you build your project on 4.0? Give it a try and see what happens.
After talking to the company about their CRM setup, they explained there were two servers dedicated to running async plugins. It appears that Microsoft Dynamics CRM always runs the plugins on whatever server initiated the update. Normally, that would be the web servers because the update is initiated by IIS. However, in this case, that would be the async servers. I simply had to install .NET 4.5 on these two servers and the problem went away.

Entity Framework 6.0.2 not working in Coded UI project on build machine

I am trying to read values from a table using Entity Framework 6.0.2 in my Coded UI project. The code works in developer system but in our build machine we are getting the following error in the line Database.SqlQuery(sqlQuery, parameters).ToList();
An exception of type 'System.Data.Entity.Core.ProviderIncompatibleException' occurred in EntityFramework.dll but
was not handled in user code
and the Inner exception is
Method not found: 'System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher System.Data.Entity.Infrastructure.Interception.DbDispatchers.get_Connection()'.
Please see the details of developer machine and build machine below
Developer Machine
Windows 7 Enterprise operating system (64 bit), Visual Studio Premium 2013 with Update 4, Entity Framework 6.0.2
Build Machine
Windows Server 2008 R2 Standard operating system (64 bit), Visual Studio Premium 2013 with Update 2, Entity Framework 6.0.2
The only difference which I could notice is the Visual Studio update but unfortunately we can not update the build machine with update 4. Another observation is, on build machine I am able to connect to database using Entity Framework 6.0.2 in my console application. The issue comes only with my Coded UI project and on that build machine.
Just to summarise the issue
Coded UI is able to connect to database using EF 6.0.2 on developer machine.
Coded UI is not able to connect to database using EF 6.0.2 on build machine.
Console application is able to connect to database using EF 6.0.2 on build machine.
Please let me know anyone has come across this issue and please let me know the solution.
Thanks,
Deepak

Error - Eclipse client trying to reconnect to TFS - "LocationWebService"

When eclipse tries to reconnect to TFS (username.visualstudio.com) the 'authentication window' is replaced by a window that seems to describe available services and the authentication process stops here.
The content of this window is as follows:
LocationWebService
The following operations are supported. For a formal definition, please review the Service Description.
ConfigureAccessMapping
Connect
QueryServices
RemoveAccessMapping
RemoveServiceDefinitions
SaveServiceDefinitions
SetDefaultAccessMapping
With VS2010 I can still connect to TFS without problems.
Also, both with eclipse and VS2010 I can connect to codeplex (tfs).
Clearing cookies and/or cache from IE or Chrome doesn't help.
Everything is fresh installed, so I assume it's up to date.
How can I resolve this issue with Eclipse - TFS - username.visualstudio.com?
I had to reinstall the 2013 version (https://www.microsoft.com/en-us/download/details.aspx?id=40785) and everything started working. It's either a bug in an older version or mismatch with the server version being connected to.
I have this issue too. It only happens when I try to connect myuser.visualstudio.com, with my domain TFS it can authenticate without any problem.
I see that you are running Windows 7, in my case the eclipse TFS stop working with Windows 8.

Active Report closing VB6 Application

I am running a VB6 with ActiveReports Standard v2 sp3. All of the sudden on one installation when creating a report the application shuts down. Eventually the system wants to report the error to Microsoft on actrpt2.dll Version 2.0.0.1252. If I copy the the clients database down on my machine it runs just fine. We have tried it on several machines. I have reinstalled the application. Reregistered the DLL. The client is using a terminal server running Server 2003. It is simply a columnar report.
I would have suspected a dependency issue for actrpt2.dll.
Check the dependency on your machine and do the same on the clients machine that this is failing.
For details on checking dependency
May be it is best to contact Grape City folks their forum is pretty active.
Update: if you are using win32 version of AR (not the dot net version of active reports).
Try dependency walker to check dependancy

TFS2008 to TFS2010 migration upgrade

All,
I'm currently in the process of attempting to create a repeatable process for the upgrade of a TFS 2008 installation to new hardware in what Microsoft call a migration upgrade, but am experiencing issues when building the VS 2008 projects on the new hardware.
Our TFS 2008 installation consists of two machines; one which houses the SQL databases and Application Tier, and the other which acts as a dedicated Build Server.
The new hardware for our TFS 2010 installation consists of two machines; one which houses the SQL databases, Application Tier, SharePoint and the Reporting Services.
So far, I have managed to successfully repeat the backup of the necessary TFS databases from the original server to the new server and restore them, followed by the 'tfsconfig import' command to successfully import and upgrade the databases to a Team Project Collection. The Team Project Collection appears correctly, and it is immediately usable. All security settings, shelvesets, workspaces etc. are intact.
Our issues start when we begin trying to build solutions. We are initially trying to build these solutions without upgrading them to the VS 2010 format, nor modifying the target Framework of any of the projects.
We get the following errors when various projects build:
< filename>.resx(x,y): error RG0000: Could not find a type for a name. The type name was 'System.Collections.Generic.List`1[[< class>, < assemnbly>, Version=a.b.c.d, Culture=neutral, PublicKeyToken=9557797252b44220]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Line x, position y. [< projectfilename>]
ResGen : error RG0000: Could not load referenced assembly "< filename>.dll". Caught a FileNotFoundException saying "Could not load file or assembly '< filename>.dll' or one of its dependencies. The system cannot find the file specified.". [< projectfilename>]
Various 'ambiguous' MSBuild target references when compiling workflow-related projects:
C:\Program Files (x86)\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.Targets (153): 'GeneratedCodeAttribute' is ambiguous in the namespace 'System.CodeDom.Compiler'.
There are various suggestions about how to eliminate these issues, including modifying the 32-bit support flag on ResGen, or forcing the use of the 64-bit ResGen, and upgrading projects to VS 2010 format and changing them to target Framework 4.
Issue 1. can be fixed by changing the offending projects to target Framework 4, however this particular project cannot be upgraded yet due to compatibility issues, and I have not yet found a solution for issues 2. & 3.
We have upwards of 20 Team Projects, with multiple branches in each, and would therefore (due to the amount of work involved) like to avoid manually changing all projects/solutions (especially as some products cannot be upgraded to Framework 4 yet for compatibility reasons, and building Framework 3.5 targeted projects in Framework 4 MSBuild does not appear to be as compatible as Microsoft would have us believe).
If anybody has any ideas which may prove helpful, then please let me know.
Cheers,
Antony
EDIT:
Issue 1 has been seen by other people, and relates to resource files referencing generic lists of a custom type. As it turns out, these were superfluous in our project, so I simply removed them, and that build issue was history.
Issue 2 seems to have dissappeared all by itself, possibly as a result of fixing issue 1.
Issue 3 relates to building VS2008 Workflow projects in MSBuild 4, when they target Framework 3.5. Microsoft, in their infinite wisdom, have apparently chosen to not address this issue (Link to Connect site), and there are several ideas to fix it (referencing specific versions of the Framework, changing the build workflow to use MSBuild 3.5), none of which work.
So our upgrade to 2010 is on hold it would seem, until either the products for which we build the 3.5 workflows (CRM 4.0 and SharePoint 2007/2010) support Framework 4, or until Microsoft fix the issue.
EDIT:
Microsoft have admitted that there is an issue, and have released the following information relating to the above KB number: http://support.microsoft.com/kb/2023579
As stated in my commented addition on my original post, this issue relating to the workflows not building is indeed resolved by a patch for the Microsot .Net Framework 4 Extended, which is outlined in KB2023579, which has not yet been made public (at the time of this post).
This solution was provided by Microsoft through a support call, and as such I am bound by the terms and conditions of that call, which prevent me from distributing a link to the patch until the official KB article is made available, at which point I will post the link. Sorry.
Hotfix that worked for us: http://support.microsoft.com/kb/2249629