This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: C# dll not recognizing string parameter encoding from InstallScript
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 18, 2009
01:14 PM
C# dll not recognizing string parameter encoding from InstallScript
Hello, first post here, hopefully someone can provide some insights on this problem:
I built a C# dll used for serial validation. It's called from within the InstallScript using DotNetCoCreateObject. I'm passing through szName, szCompany, and szSerial after receiving the data. This part all works properly,
however when the string values get passed into the DLL, weird things happen.
For example, say we have the following values:
szName: User
szCompany: Test Inc
szSerial: 123456
Inside of the C# DLL functions, it sees these string values and when I print them, they look to be correct. However if I do a String.Equals(szName, "User") inside of the DLL, it fails. String.Compare() works. So that's ok. But the problem is when I try to create a hash string from say szName, the result is different than if I create the hash with a hard coded value of "User".
So I'm suspecting there to be some kind of string encoding issue when the strings are passed into the DLL, but I'm not finding any way to fix this issue so I can correctly validate the serial using the szName, szCompany, and szSerial strings.
Does anybody know the solution?
I built a C# dll used for serial validation. It's called from within the InstallScript using DotNetCoCreateObject. I'm passing through szName, szCompany, and szSerial after receiving the data. This part all works properly,
however when the string values get passed into the DLL, weird things happen.
For example, say we have the following values:
szName: User
szCompany: Test Inc
szSerial: 123456
Inside of the C# DLL functions, it sees these string values and when I print them, they look to be correct. However if I do a String.Equals(szName, "User") inside of the DLL, it fails. String.Compare() works. So that's ok. But the problem is when I try to create a hash string from say szName, the result is different than if I create the hash with a hard coded value of "User".
So I'm suspecting there to be some kind of string encoding issue when the strings are passed into the DLL, but I'm not finding any way to fix this issue so I can correctly validate the serial using the szName, szCompany, and szSerial strings.
Does anybody know the solution?
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 21, 2009
01:15 PM
I'm having the same issue. The string return value from my .net dll is different when I call it from InstallShield 09 vs using the .net dll in my .net application. In this case it's an encryption routine to encrypt passwords to store in a database. The same method is used by my application when creating new users. However, the result of the method is different depending on where I call it from. Has anyone solved this issue yet?
Thanks!
Thanks!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 22, 2009
07:32 AM
The following solution may help you.
Keep in mind the call to managed code is going through COM interop and apparently the buffer for the string is filled with null characters. I forget how I found this, I may have popped up a Messagebox with the string. You'd see '\0' filling the buffer, which I believe is 512 or 1024 characters.
I use the following method to strip the nulls:
///
/// We are getting strings from InstallScript, via COM Interop, that are buffered
/// with null characters such that the source string is 1024 chars, buffered with '\0'.
/// This method's job is to clean up these extra nulls which cause various issues.
///
///
Keep in mind the call to managed code is going through COM interop and apparently the buffer for the string is filled with null characters. I forget how I found this, I may have popped up a Messagebox with the string. You'd see '\0' filling the buffer, which I believe is 512 or 1024 characters.
I use the following method to strip the nulls:
///
/// We are getting strings from InstallScript, via COM Interop, that are buffered
/// with null characters such that the source string is 1024 chars, buffered with '\0'.
/// This method's job is to clean up these extra nulls which cause various issues.
///
///
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 26, 2009
07:50 AM
I encountered the same issue. I placed my return value into a list first.Here is my code I used to fix the issue:
// Remove new line character from end of
szDelimiterSet = "\n";
StrGetTokens ( lstGuids, sValue, szDelimiterSet);
switch (szDelimiterSet)
case "\n":
szToken = "";
nResult = ListGetFirstString(lstGuids, szToken);
while (nResult != END_OF_LIST)
nPos = StrLength(szToken) - 1;
if (0 <= nPos) then
if (0x0D = szToken[nPos]) then
szToken[nPos] = '\0';
ListSetCurrentString(lstGuids, szToken);
endif;
endif;
szToken = "";
nResult = ListGetNextString(lstGuids, szToken);
endwhile;
endswitch;
// Remove new line character from end of
szDelimiterSet = "\n";
StrGetTokens ( lstGuids, sValue, szDelimiterSet);
switch (szDelimiterSet)
case "\n":
szToken = "";
nResult = ListGetFirstString(lstGuids, szToken);
while (nResult != END_OF_LIST)
nPos = StrLength(szToken) - 1;
if (0 <= nPos) then
if (0x0D = szToken[nPos]) then
szToken[nPos] = '\0';
ListSetCurrentString(lstGuids, szToken);
endif;
endif;
szToken = "";
nResult = ListGetNextString(lstGuids, szToken);
endwhile;
endswitch;