Windows 7 - Enable Network DTC Access - windows

I have a Visual Studio 2010 Windows Forms application in which I start a transaction using the TransactionScope class. I then Receive a message from a Sql Server Broker Services message queue, which works fine. I next try to call a stored procedure from the same database with a call to my data access layer which is a Visual Studio dataset (xsd file). When I make this second call to the database I get the following error message:
The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B).
I've seen several posts on the web that talk about Enabling DTC access through dcomcnfg.exe, and allowing DTC to communicate through Windows Firewall. I've done those things, and am still having this problem. I know our remote database server is setup to Enable DTC access, because we are using similar transactions in other projects built with Visual Studio 2008 on Windows XP and Vista. I think there is something specific about Windows 7 and Visual Studio 2010 causing this problem, but haven't been able to find out what it is. Can anyone help with this problem?
I just saw a post on the web from another programmer having this problem (http://www.pcreview.co.uk/forums/thread-3977150.php), he says it works fine on Windows 7 - x86, but gets this error on Windows 7 - x64. I'm running the x64 version of Windows 7, does anyone know if there are problems with MSDTC on Windows 7 - 64 bit version?

It turned out that I was leaving a database connection open in my Receive call to the SQL Server Service Broker, then trying to make a new connection to my data access layer. That was causing the problem, the fix turned out to be to close the first connection before opening the second one.

Related

VS 2013 Setup Projects Works on one server and does not on another

We recently migrated from VS 2008 to VS 2013 including a set of setup projects. One of the setup projects is meant to install a web application. It has one custom action that is meant to check the connection to the database. The code of the custom action has not been touched during the migration and the .msi works perfectly when generated from VS 2008. When I built the .msi from VS 2013 it works perfectly well when installing on our local development server, and throw an error saying that it cannot connect to the db when rolling out in the clients environment.
I'd really appreciate if anyone can point me into direction of search here. I know that I'm passing a correct connection string, and .msi generated from VS 2008 can connect to that db from the same server.
Visual Studio custom actions that are installed for Everyone will run with the local system account. Connecting to a SQL DB will often fail because the DB doesn't allow the system account to connect, or because the DB is on a network share and the system account has no network privileges.
So it could fail because of the security settings of the DB or because the DB is on a network, and it may be nothing to do with the server. It might also connect if the install runs with a Just me setting because the custom actions then will run with the installing user's credentials. There may also be issues with architecture because servers are 64-bit and the 32-bit subsystem is optional, and you didn't say whether you install was x64 or your custom action code.

Unable to get VS2010 to connect to remote debugger on Windows 8 PC

I have a Win 7 64 bit PC running VS2010
I have one test machine that is generating issues for me (a Win 8 one), but I cannot connect to it via Remote Debugger.
To complicate issues, this remote machine is a VM hosted via Paralells.
I have turned off all firewalls (I don't like this, but that makes the server appear in the VS2010 window, so I know I need to come back and tweak the firewall.)
I go to the remote machine, start up vsmon (I have tried both x86 and 64 versions), and the server starts ok.
try to connect and I get "MSVSMON.exe does not appear to be running on the remote instance." (Even though I know it is as I just started it!)
I have gone into settings and enabled "Any User" and "No Authentication". Restarted VS2010 and still nothign. Exactly the same error message.
I have a User called Matt on both the Win 7 and Win 8 machines, both with admin rights to the resepctive boxes. But still the same error message.
So what steps have I missed?
(and as a supplemental, I am sure that in teh documentaiton for the remote debug server download, it states that the install will create the necessary firewall rules, so why is my firewall still blocking me seeing the Win 8 Machine?)
Im out of ideas on this one, so if I can't crack this soon I'll have to move my dev envrionment across to the win 8 vm lock stock and barrel, which then means that my test machine is no longer an exact replica of a client workstation.
Copy directory c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\ to the remote computer.
Start x64 version of msvsmon.exe as user Matt. Do not enable "Any User" or "No Authentication". User Matt should have administrator rights.
Start your visual studio 2010 as Matt.
Try to connect to remote debugger. It worked for me every time. If it does not, consider using higher version of visual studio (i.e. vs 2013 community edition is free and should work well).

Project migrated from old PC and from VS2010 to VS2012 "The wait operation timed out."

I just got a new Windows 7 computer with VS 2012. My old box was Windows XP with VS 2010. I copied over my project and had VS2012 upgrade the project and get the following error when running the ASP.NET MVC 3 application:
[Win32Exception (0x80004005): The wait operation timed out]
[SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The wait operation timed out.)]
[ProviderIncompatibleException: The provider did not return a ProviderManifestToken string.]
[ProviderIncompatibleException: An error occurred while getting provider information from the database. This can be caused by Entity Framework using an incorrect connection string. Check the inner exceptions for details and ensure that the connection string is correct.]
That was the order of the messages. I am connecting through EntityFramework (code first). The connection string was working just fine in VS2010:
Data Source=xxx.xxx.xxx.xxx; User ID=xxxxxx; Password=xxxxxxxxx; Initial Catalog=xxxxxxxxx; MultipleActiveResultSets=true
I have been searching for hours with no real solution. The only one I haven't tried is to remove VS 2012 and .NET 4.5. That would be a problem since then I can't code. I have tried to remove .NET 4.5, but then VS2012 doesn't start. I have installed .NET 4.0.
I have installed (only listing software based on what I have see in searches):
VS 2012
Windows 7
SSMS 2010 (which was initially installed after VS 2012)
I have done a repair on VS2012 as well. I have not uninstalled and reinstalled it.
Any thoughts? I am going nuts here. Right now I have a quad-core pc that can remote desktop REALLY fast to my old clunker.
NOTE: My firewall is off. I have Symantec Endpoint Protection and this is connecting to a live SQL server, so I know it's running.
Amazingly, this worked:
netsh Winsock reset
See Can't connect to database after installing VS 11 Pro Beta

Visual FoxPro (9.0) issue on Microsoft Windows Server 2003 R2

We have been running a Visual FoxPro (version 9) application on a Server under Microsoft Windows Server 2003 Operating system for a number of years now. We are now trying to migrate it to a different Server running under Microsoft Windows Server 2003 R2 and the application crashes. The problem occurs when it is trying to create HTML files from the FoxPro reports it has just created. To do this is uses the system variable _ReportOutput and aborts with the message “ox is not an object”. The application resides on the Network in a directory accessible to both Servers. Since hitting this problem I have changed the program to use the Htmllistener class within _ReportListener and get the same problem (works on one not on the other (R2)). Wait windows have been inserted to gain additional information but they only show that the object has not been created returning a data type of .Logical. It appears to me the problem is with the R2 version of the operating system, has anybody any ideas.
Have you installed ReportOutput.APP in the same folder as the application?

Catastrophic failure on IIS Web Service when calling a COM method

Maybe the worst type of error message that one can see. Does not mean anything, may be related to everything...
I try to create a web service (WS) on IIS 7.5 (I have initially tried WCF services but same story)
The WS uses a COM DLL which is successfully registered and the COM security permissions are given.
When I run the WS using Visual Studio Development Server everything is fine, I get the results as requested. But when I try to deploy the WS to IIS, I end up with
System.Runtime.InteropServices.COMException: Catastrophic failure
My computer has Windows Server 2008 R2 Standard, x64.
I have to emphasize: I develop (using Visual Studio 2010 Ultimate), test (using Visual Studio Development Server) and deploy (using IIS 7.5) on the same computer.
I was thinking that the problem might be related to 32-64 bit incompatibilities, as my COM is supporting 32 bits. Therefore, I changed the application pool settings to enable 32 bit applications, changed the platform target to x86 in Visual Studio, redeployed the WS, none of these helped.
My question is:
How can a WS successfully run on VS Development Server but fail on IIS? What else shall I change in IIS settings?
It really helps to consult the producer of the COM DLL. They have given a clear installation procedure for the DLL, that I have somehow omitted.
Moral of the story: Although your web service or web site operates successfully under Visual Studio Development Server, this does not necessarily mean that you have configured all settings for the COM DLL correctly.
You can start checking the following issues:
Register the COM DLL
Check configuration settings using dcomcnfg
If your DLL does not appear in dcomcnfg lists, then probably you did not register it correctly. Some registry editor entries are probably missing.
Check your IIS application pool settings
You may need to impersonate in web.config
Check the event viewer. It might include some important clues
In my case, I was playing with all of these items, but never in the correct sequence. Finally the help from the producer has arrived which was showing the correct path.

Resources