Every time I try to add the Interactive Brokers API control on my computer it gives me an error that sais....
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. (Exception from HRESULT: 0x800736B1)
I have been looking for an answer and trying different things for a week now and I can not seem to figure it out. I tried it on my laptop and it worked. I thought it was my windows or my visual studio so i re-installed everything on my PC. I'm not running a Windows 7 Professional x64 with Visual Studio 2013 with the newest update. At this point I have no idea what to try to make it work. Does anybody know what is this error.
Sorry-very late for an answer to this but in case someone else comes across it. There are a number of reasons why Visual Studio might not be able to add the control to your application. For 64-bit windows, one of the main issues is that the ActiveX control (tws.ocx) is not registered properly when the API is installed. I have a web page dedicated to installing IB API on Windows and I list out many of the issues that can happen when working with the ActiveX control on 64-bit windows: http://holowczak.com/ib-install/
I just posted a very simple tutorial on my website that starts at the very beginning and walks you through getting the API to work with interactive brokers using Visual Studio and C# : Get Real-Time Stock data from Interactive Brokers API
If that doesn't help I would consider:
Turn off Windows Firewall and give it a try.
Ensure you have Traders Workstation setup to allow incomming connections for ActiveX/.NET.
Ensure Traders Workstation works on your machine. Try downloading it from IB and launching it. If it works, then the problem is on the .NET or connection from .NET to TWS which is Java.
Also when you say "Interactive Brokers Control" do you mean the API package that you can download? If so to build it into your program all you need is the .DLL file as shown in the tutorial link I posted above.
Related
I have a .NET application that regularly works on all the machines with .NET installed.
When I try to launch it on a PC with no .NET framework installed this happens:
it opens, i can change tab (my app has 4 tabs), it reads the computer IP without any problem, but then crashes somewhere when it receives a message from another terminal (i have a terminal that communicates with the PC via ETH-TCP/IP).
The message I get is just:
DESCRIPTION: stopped working.
The big deal is that I cannot debug it because if I install the .NET framework it magically works like a charm.
Obviously I'm asking this because we prefer not to install .NET on all the machines in the office (they run different Windows versions and plenty of them don't have the .NET installed).
My question can be similar to this one, but in my case the .exe starts (as I explained above).. the crash comes when I start the communication between the PC and the terminal.
Anybody has a hint for my problem? Thank you
EDIT : thank you for the answers, in the end I decided to do Remote Debugging by running the app on a virtual machine with no .NET at all. Now, when it crashes, I can catch the bad instructions inside VS2010 installed on the host machine.
Btw, the problem was on a .dll that couldn't be loaded
You must have the .NET Framework installed on a machine in order to run a .NET application. The .NET Framework is both a runtime and the SDK, not just an SDK. All versions beyond Windows XP come with some version of the .NET Framework installed.
If you are saying that installing Visual Studio corrects the issue (which is what the question you linked to describes), that is a different problem altogether. Unfortunately, your question doesn't provide enough information to troubleshoot it. You can check the Event Viewer on the machine experiencing the issue, then look for two errors next to each other in the Application event log. One of these errors will contain exception detail, which will aid us (or you) in tracking down the problem.
I've designed a WPF C# application using Visual Studio 2012. The application, which is simple enough, runs fine on my Windows 8 machine using the ClickOnce deployment method. The datagrid displays the content from a SQL Server database and performs all of it's other functions just as I've designed it to, but when I attempt to install it on a Windows 7 machine it immediately crashes and I'm not sure why. The Windows 7 computer I'm trying to install the application on has .NET 4.5 running on it, but is there anything else that computer needs to have installed on it in order to run applications developed with VS 2012. This is my first attempt to install an application developed with VS 2012 on a Windows 7 machine, so I'm not sure if there's another step that I'm missing here. Any help you guys can provide would be greatly appreciated. Thank you.
The message you stated "The application has stopped working and that if Microsoft has a solution..." is an indicator of one of the following:
The Framework is disabled; though 4.5 is installed several root instances are built on the foundation which are apart of Framework 2.0. This particular Framework can cause issues for 3.0, 3.5, 4.0, and even 4.5.
The System.EnterpriseServices.dll is damaged in the Framework. Which needs to be connected back to the Global Assembly Cache (GAC).
And another common issue is the machine.config file log in the Framework Folder can be corrupt and needs to be replaced with a valid one.
There are others that can occur within the System Policy Folder as well, which may require you to use the .Net Cleanup Tool and reinstall the Framework. But before you do any troubleshooting you should go to the Event Viewer and get details of what is going on.
Try these steps first for me:
Windows Key + R
When the run prompt appears type: appwiz.cpl
Go to the left hand side: Turn Windows Features On or Off
Turn Framework 3.5 on if it isn't already; if it is already on go to Step 5.
Turn off the Framework; then reboot.
Once rebooted follow steps 1-4 again.
Now at this point I would suggest trying the application again. If it fails try this:
Open Start
Type 'cmd' in Search
Right Click and Run as an Administrator
Type %windir%\Microsoft.Net\Framework\v2.0.50727\ngen.exe update
Then type: sfc /scannow
The Native Regeneration tool will try to repair the Framework back to a factory state; the System-File-Checker will attempt to fix any errors indicated in Windows. If it can't it will say 'it found integrity violations'.
Those are the steps I would do for general support; but you really should try and locate an error message. As the Framework can become a huge ordeal to cleanup and fix. If you provide more information I will revise my response to help address it.
Hopefully that helps.
I am running into an issue when attempting to use MapPoint libraries within our C# .NET application from a published app on a Windows Server 2008 machine. When instantiating the MapPoint.MapClass, I get the error:
"Your registry settings for this application were not copied correctly. To correct these settings, run Setup again for this application from the location where you originally installed it."
I am able to launch MapPoint just fine by itself outside of the app, the error only comes up when running the published app. We have multiple servers that clients run the app on, and the server running Server 2003 is able to launch MapPoint just fine. In addition, XP and Win7 machines also work fine. We also have a Foxpro application that also utilizes MapPoint's API installed on the 2008 server, and it doesn't have any issues.
MapPoint is included as a COM reference in the VS project referring to "Microsoft MapPoint 13.0 Object Library (North America) 8.3".
Looking online, I found a bunch of possible solutions, but nothing worked. I have tried:
Uninstalling MapPoint 2006 entirely and manually removing all entries from the registry, then reinstalling
Doing the same as 1 but then installing the trial of MapPoint 2011, resulting in the exact same error message
Disabling UAC
Setting MapPoint.exe's compatibility mode to Server 2003 and XP
Please let me know if anyone has any other suggestions.
it does sound like something is partially installing / being blocked. Is this a user issue? Ie. Can you install for all users?
it doesn't explain the MP2006 issue, but I would avoid the trial version for API work - the trial nag screen can be a problem. Eg. If you start the app hidden, the user cannot always see the nag screen to dismiss it.
You say you are instantiating a Map class. What about the Application (or _Application) class: you must have one of these to create the Map.
I have an error very similar to the one addressed in this question. I am trying to deploy a small c#/Xaml utility on 6 work machines. 4 of the machines run the utility successfully and 2 do not. All machines are windows XP and have .Net frameworks 1-4 installed (my app is compiled against 4.0 and all machines have both client and extended redistributables installed).
On running the utility, I get the standard "... has encountered a problem and needs to close." On viewing the error report contents, the problem seems to occur in System.Windows.Markup.XamlParse.
I have run .Net 4.0 online installer in "repair" mode and still I get the same problem. I have tried all the suggestions from the post linked above:
The file is deployed alongside a DLL which is present and correct.
UI cultures are identical.
All computers are up to date from Microsoft Update.
The assembly does not contain any external resources which are referenced in XAML.
I don't really know where to start with debugging this one. Any suggestions?
I would suggest setting up remote debugging on the machines that are having the problem and then adding this to the startup code:
while (!System.Diagnostics.Debugger.IsAttached)
{
Thread.Sleep(100);
}
I have a relatively simple ASP.NET application that I am trying to create an installer for. I am currently using Visual Studio 2008's "Web Setup Project" which, though I'm told is not ideal, has proved no problems when installing on Windows Server 2003 & IIS6.
IIS7 on Server 2008 and Vista has proved substantially more difficult. The installer starts off fine before halting with an unhelpful "The installer was interrupted before could be installed. You need to restart the installer to try again." UAC is switched off, and I've already ensured I'm executing the installer with administritive privledges.
The problem sounds identical to the issue outlined in this blog post, however I have the IIS6 Metabase Compatibility role service installed already. I've also tried playing around with AppPools, the Integrated/Classic pipelines and so on, all to no avail.
I've since turned on MSI logging and, whilst I found nothing concrete, I believe the rollback begins somewhere around this error message.
The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible.
This doesn't make any sense to me whatsoever, as both Vista and Server 2008 are 32-bit installations. I suspect it's a red herring, but I can't be sure.
Has anyone encountered a similar problem, and if so, is there a solution that doesn't involve me moving to a different installation framework?
Try putting a friendly lil checkmark beside each node in
[Programs and Features // Turn Windows features on or off // Internet Information Services // Web Management Tools // IIS 6 Management Compatibility]
Note that I had the same symptoms posted in the blog though, and this fixed it for me. Yours may be different.
Just tackled this last night, therefore my sincerest good luck to you.
In order to fix that error message for those using Windows 2003 x64, use the following commands from a cmd prompt:
cscript.exe %SystemDrive%\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 "true"
cd WINDOWS\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis.exe -i
Source:
How to Run a Microsoft .NET 2.0 or higher Web Application in 32-bit Mode in IIS 6.0 on a 64-bit Server
Note:
By doing the first step, you will now notice that the ASP.net tab is no longer visible.
This is a known bug and the work around is too use scripts to change the .Net version for any running sites.