VB6 dll calls from WCF
-
That doesn't answer my question; write the name of the current user to a logfile or similar to check.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I don't understand which user you're referring to
-
Hi everyone, I created a library of the WCF service, which recalls a VB6 dll. The problem is this: in the procedures of the VB6 dll (not my owner) strange errors occur (especially with dates), if the initial process that hosts it is the WCF service. Everything works correctly if the initial process is a VB6 executable, a VB.NET executable, or if I run the VB6 project in debug. Among the many attempts I set all my projects with CPUs targeting x86, and although I had no problems compiling the WCF service, I also tried to replace WcfSvcHost.exe with the same in 32-bit mode (with the command "corflags / 32BIT + / FORCE WcfSvcHost.exe "), but the problem persists. Actually I don't think it's even necessary, as the hosting of the WCF library is an application console. I have no idea how to solve ... can anyone help me?
VB6 can only make COM-exposed .DLL's. I don't know if that means or affects anything, but there it is. Without seeing the code that's calling the functions in the .DLL, and the error messages coming back from SQL Server, it's going to be impossible to tell you anything useful. The biggest problem is we can see the code in the VB6 .DLL, so we don't know what it expects in the function calls.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
I don't understand which user you're referring to
Environment.UserName All the code runs under specific credentials. Your hosted service may not be running as a default user.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
VB6 can only make COM-exposed .DLL's. I don't know if that means or affects anything, but there it is. Without seeing the code that's calling the functions in the .DLL, and the error messages coming back from SQL Server, it's going to be impossible to tell you anything useful. The biggest problem is we can see the code in the VB6 .DLL, so we don't know what it expects in the function calls.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakI do not have the VB6 dll source from my provider, so I have no way of getting the error.
I am attaching images of errors captured by SQL Profiler, but I don't think they can help.
The 1.png, 2.png and 3.png files are screenshots of the SQL profiler traces captured at Runtime, while the 1_Debug.png, 2_Debug.png and 3_Debug.png files are screenshots of the SQL profiler traces captured in Debug (so working).Since the errors do not occur by calling the VB6 dll from VB6 or VB.NET applications, or by debugging my VB6 project which instantiates the external dll, I thought the problem lies in the process that hosts it.
https://drive.google.com/open?id=1Wziux18JvKzx-7DtBMTSfrOT5TuANVVF
-
Environment.UserName All the code runs under specific credentials. Your hosted service may not be running as a default user.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I wrote the current user in my log file, and it matches with the Windows credentials I logged in with ... so it's ok.
-
I do not have the VB6 dll source from my provider, so I have no way of getting the error.
I am attaching images of errors captured by SQL Profiler, but I don't think they can help.
The 1.png, 2.png and 3.png files are screenshots of the SQL profiler traces captured at Runtime, while the 1_Debug.png, 2_Debug.png and 3_Debug.png files are screenshots of the SQL profiler traces captured in Debug (so working).Since the errors do not occur by calling the VB6 dll from VB6 or VB.NET applications, or by debugging my VB6 project which instantiates the external dll, I thought the problem lies in the process that hosts it.
https://drive.google.com/open?id=1Wziux18JvKzx-7DtBMTSfrOT5TuANVVF
-
-
I don't have the error because the VB6 dll is not mine, but with SQL profiler I found errors in the queries due to lack or incorrect formatting of dates.
Emanuela Meraglia wrote:
errors in the queries due to lack or incorrect formatting of dates
That would suggest that the VB6 code is vulnerable to SQL Injection[^]. It it was using properly parameterized queries, date formatting wouldn't be an issue. This is a serious security vulnerability. You should either get the author to rewrite the VB6 code, or find some way to replace it.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I wrote the current user in my log file, and it matches with the Windows credentials I logged in with ... so it's ok.
-
Emanuela Meraglia wrote:
errors in the queries due to lack or incorrect formatting of dates
That would suggest that the VB6 code is vulnerable to SQL Injection[^]. It it was using properly parameterized queries, date formatting wouldn't be an issue. This is a serious security vulnerability. You should either get the author to rewrite the VB6 code, or find some way to replace it.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
They are rewriting it, but in the meantime I have to use their dll VB6! :(
-
All the messages seem to be complaining about the syntax of the SELECT clauses (assuming my innterpretation of the Italian is coorect), and suggesting that it has something to do with the Date values. I think the only way to resolve this is to talk to the owners of the DLL.
-
Hi everyone, I created a library of the WCF service, which recalls a VB6 dll. The problem is this: in the procedures of the VB6 dll (not my owner) strange errors occur (especially with dates), if the initial process that hosts it is the WCF service. Everything works correctly if the initial process is a VB6 executable, a VB.NET executable, or if I run the VB6 project in debug. Among the many attempts I set all my projects with CPUs targeting x86, and although I had no problems compiling the WCF service, I also tried to replace WcfSvcHost.exe with the same in 32-bit mode (with the command "corflags / 32BIT + / FORCE WcfSvcHost.exe "), but the problem persists. Actually I don't think it's even necessary, as the hosting of the WCF library is an application console. I have no idea how to solve ... can anyone help me?
Checking the VB6 code with the developer, we have identified the point where the error occurs: it cannot return a path of the configuration file (from which it reads the formatting of the dates), and uses the Windows API "GetEnvironmentVariable" .
I'm trying to figure out if there is any incompatibility between WCF and the VB6 API calls. -
Checking the VB6 code with the developer, we have identified the point where the error occurs: it cannot return a path of the configuration file (from which it reads the formatting of the dates), and uses the Windows API "GetEnvironmentVariable" .
I'm trying to figure out if there is any incompatibility between WCF and the VB6 API calls.If you're hosting the WCF service in IIS or a Windows Service, it will be running under a different profile. Unless the environment variable is set as a system variable, it will be specific to your user profile, and will not be available to the WCF code. Environment variables in Windows NT[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
If you're hosting the WCF service in IIS or a Windows Service, it will be running under a different profile. Unless the environment variable is set as a system variable, it will be specific to your user profile, and will not be available to the WCF code. Environment variables in Windows NT[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I'm hosting the WCF service in a windows service
-
I'm hosting the WCF service in a windows service
So unless the environment variable is registered as a "system" variable, it won't be available to the WCF service.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I don't have the error because the VB6 dll is not mine, but with SQL profiler I found errors in the queries due to lack or incorrect formatting of dates.
-
The error also occurs on my development PC, on which everything is executed. So I don't think it's a problem of regional settings.
Let us reverse Engineer it, I have come across these types of situations a lot time ago. Here is the clue, you said you are able to execute the application and the same dll as exe right? Check what Date formatting is it being used there and one more advice is, go to the stored procedure because you are able to find the stored procedure using the SQL Profiler right? Try to execute the SP by passing the different Parameters and replicate the same error, then you would know what formats the SP is accepting and what formats the sp is giving the errors and why? Then you can fix the issue in the Web Service to use the same format - what you are going through is similar what many have sometime back when everything moved from VB6 to .Net Framework - but its OK. You are doing a great Job - best of Luck.:thumbsup:
-
I do not have the VB6 dll source from my provider, so I have no way of getting the error.
I am attaching images of errors captured by SQL Profiler, but I don't think they can help.
The 1.png, 2.png and 3.png files are screenshots of the SQL profiler traces captured at Runtime, while the 1_Debug.png, 2_Debug.png and 3_Debug.png files are screenshots of the SQL profiler traces captured in Debug (so working).Since the errors do not occur by calling the VB6 dll from VB6 or VB.NET applications, or by debugging my VB6 project which instantiates the external dll, I thought the problem lies in the process that hosts it.
https://drive.google.com/open?id=1Wziux18JvKzx-7DtBMTSfrOT5TuANVVF
What Dave said might be correct too, since Service is to transport the Data it must be Serializable or Distributed that would be a problem but to know the real problem - try to replicate the issue on Stored Proc by passing different Date formats as I can guess you have only one source code that's exposed to you all other are either dlls or exes, which you can't reverse them into VB6 code back. So focus on one Source Code you may probably have or know that's SP and try to replicate the problem.
