I am assuming that the access token once obtained can be used in other sessions (subject to a single session being active) till it gets invalidated which I guess is once per day. I can also see this is a valid assumption, since whenever I launch the Kite Connect .Net library, login from browser and pass the request token back into the code, I get back the same access token that I got when I connected for the very first time.
So by using your library, I could connect fine and get the quotes. However, when I tried to call the C# API dll (KiteConnect.dll) from a VB.Net front end, I get errors that the connection is being refused.
So, I separated out the raw websocket code from your C# library that handles the connection. It goes like this: //TO DO: Remove the below direct web socket creation ClientWebSocket ws = new ClientWebSocket(); ws.Options.SetRequestHeader("X-Kite-Version", "3"); ws.ConnectAsync(new Uri("wss://ws.kite.trade/?api_key=<<api key>>&access_token=<<access_token>>"), CancellationToken.None).Wait(); Console.WriteLine("OK");
The above works fine.
Now the same code in Vb.Net Dim ws = New ClientWebSocket() ws.Options.SetRequestHeader("X-Kite-Version", "3") ws.ConnectAsync(New Uri("wss://ws.kite.trade/?api_key=<<api_key>>&access_token=<<access_token>>"), CancellationToken.None).Wait() Console.WriteLine("OK")
This generates the below exception: Error while connecting. Message: No connection could be made because the target machine actively refused it 127.0.0.1:8888
Please note that the api key and access token are exactly the same in both the versions. Why am I getting this error?
The compilation target of the project if set to x64 causes this issue. The KiteConnect libraries are compiled under AnyCPU. If we change it x64, we will get the error in the library also. Why this should be so? Why cant I use your API targeting only x64 platforms?
@shortwire The reason we decided to build it for AnyCPU is that we have users who are still on x86 windows versions. You can change and rebuild it as per your requirements.
Also, from the exception message above I believe there is a proxy sitting in between the connections and it is not live. And I guess "127.0.0.1:8888" is the address of that proxy. Are you using Fiddler or any similar HTTP debugging tools?
Its not a proxy I am behind. Neither am I behind any http sniffers. If it was so, the C# code in the sample project from your library would have given the same problem too.
The sample project from the .Net library works fine as the sample is build using Any CPU. You can check by changing the sample project from Any CPU to x64. The error that I mentioned above will come in your case too.
So the question is if an implementing program (in this case a client), calls your .Net library DLL (in this case KiteConnect.dll), it has to be targeted to Any CPU for it to work. If you change the client caller platform to x64 and call the websocket connect via KiteConnect.dll or directly invoking the socket, it will throw the error.
Please advice why. While I understand the reasons that you build the library with Any CPU option, however the core rest API call should not be limited to the way client compilation platform is targeted. Whether the client is compiled in x86, x64 or Any CPU the rest services for the web socket connection should work - isnt it?
Just to clarify further, just try making a raw call to websocket connect. Steps to simulate: 1) Open a new Visual Studio project - any language - C# or .Net (console or windows forms) 2) Make sure the programs compilation option is x64 and not Any CPU 3) Add the System.Net reference and System.Threading reference. 4) Write the below code under lets say a Button click
Note that I have not used the official library and just making a direct call to the websocket from a new .Net project that is compiled with target platform as x64.
@shortwire I tried the same thing on my system and it works fine. I didn't get any error or exception. I strongly suggest you to double check your proxy settings in Internet Options.
The compilation target of the project if set to x64 causes this issue. The KiteConnect libraries are compiled under AnyCPU. If we change it x64, we will get the error in the library also.
Why this should be so? Why cant I use your API targeting only x64 platforms?
Also, from the exception message above I believe there is a proxy sitting in between the connections and it is not live. And I guess "127.0.0.1:8888" is the address of that proxy. Are you using Fiddler or any similar HTTP debugging tools?
Its not a proxy I am behind. Neither am I behind any http sniffers. If it was so, the C# code in the sample project from your library would have given the same problem too.
The sample project from the .Net library works fine as the sample is build using Any CPU. You can check by changing the sample project from Any CPU to x64. The error that I mentioned above will come in your case too.
So the question is if an implementing program (in this case a client), calls your .Net library DLL (in this case KiteConnect.dll), it has to be targeted to Any CPU for it to work. If you change the client caller platform to x64 and call the websocket connect via KiteConnect.dll or directly invoking the socket, it will throw the error.
Please advice why. While I understand the reasons that you build the library with Any CPU option, however the core rest API call should not be limited to the way client compilation platform is targeted. Whether the client is compiled in x86, x64 or Any CPU the rest services for the web socket connection should work - isnt it?
1) Open a new Visual Studio project - any language - C# or .Net (console or windows forms)
2) Make sure the programs compilation option is x64 and not Any CPU
3) Add the System.Net reference and System.Threading reference.
4) Write the below code under lets say a Button click
ClientWebSocket ws = new ClientWebSocket();
ws.Options.SetRequestHeader("X-Kite-Version", "3");
ws.ConnectAsync(new Uri("wss://ws.kite.trade/?api_key=<<api key>>&access_token=<<access_token>>"), CancellationToken.None).Wait();
Console.WriteLine("OK");
5) Run
Note that I have not used the official library and just making a direct call to the websocket from a new .Net project that is compiled with target platform as x64.
You would see the error coming up.