Grigs

Hello,

I have a Windows Forms application written in C# via VS 2003. It does 100% of what it should while in Debug mode. However, there is one thing it does not do when compiled in Release mode. There is an external .dll I have to connect to, to do a screen scrape of an AS400 application. The linking of it is as follows:

[DllImport("PCSHLL32.dll")] public static extern UInt32 hllapi(out UInt32 Func, StringBuilder sbData, out UInt32 Length, out UInt32 RetC);

When I run in Debug mode it connects and gives me the correct return code of 0 which = Success. However, when I run in Release mode I get a different return code of 10 which is Unsupported.

There is no code difference between modes. I have no #debug or anything onther than the exact code. The only thing I can figure is perhaps a security difference between Debug and Release modes. Is this the case

Are there any other suggestions on how I can get this piece to work

Thanks in advance,
Kevin



Re: Visual C# General Debug vs Release

TilakGopi

Hi,

Did u checki the error code ,after capturing the return value of this API

What was specified

Thanx,

Ch.T.Gopi Kumar.






Re: Visual C# General Debug vs Release

OmegaMan

Questions
  1. Just to be clear, are you running the application in debug mode with no problems vs running it in the debugger with no problems
  2. If you are only running it in the debugger, what happens when you run the debug code outside the debugger
  3. Also one can debug in .Net release mode does the same occur
  4. Do you have the project settings "Enabled Unmanaged Debugging" set to true or false What happens when you switch settings





Re: Visual C# General Debug vs Release

Grigs

TilakGopi,

As I mentioned, I get the correct return code of 0 when in debug mode. Always 10 in Release mode.

Thank you,

Kevin





Re: Visual C# General Debug vs Release

Grigs

OmegaMan,

I tried it all four ways. Running in Debug mode in the debugger as well as then just running the .exe from File Explorer. Then running in Release mode in the debugger and running the .exe. Both Debug runs worked with the aforementioned results. And both of the Release runs failed as before.

In both debug and release configurations, the Enable Unmanaged Debugging were set to false. I set it to true and it seemed to run a bit slower but the results were the same for all.

Any other suggestions





Re: Visual C# General Debug vs Release

OmegaMan

Grigs wrote:
I get the correct return code of 0 when in debug mode. Always 10 in Release mode.


Do you build the component in question or is it an unchanging object that you bring in If it is compiled and C++, you most likely have a memory overwrite issue internal.





Re: Visual C# General Debug vs Release

Grigs

If you mean did I make the PCSHLL32.dll that I am connecting to via the DllImport NO. I did not make it. It was made by IBM and gets installed when the AS400 emulator software gets installed. So yes, it is an Unchanged / consistent object that I bring in.

If you meant did I rebuild MY application, yes I did. Once to get a fresh Debug version of it and then again (without changes) to get a fresh Release version of it.

If it is a memory overrite issue, how/what can I change to fix it

Thanks





Re: Visual C# General Debug vs Release

OmegaMan

Grigs wrote:

If you mean did I make the PCSHLL32.dll that I am connecting to via the DllImport NO. I did not make it. It was made by IBM and gets installed when the AS400 emulator software gets installed. So yes, it is an Unchanged / consistent object that I bring in.

If you meant did I rebuild MY application, yes I did. Once to get a fresh Debug version of it and then again (without changes) to get a fresh Release version of it.

If it is a memory overrite issue, how/what can I change to fix it

Thanks



Since you did not create the dll then debugging their issues is moot in terms of memory overwrites. Since you have managed code, that is ok. The only other option is how you import the dll into you code and access the functions calls. Check those items, maybe something is off and debug is more forgiving than release.

If IBM has provided you with a test application, see if that provides any clues...Good luck.





Re: Visual C# General Debug vs Release

Figo Fei - MSFT

Hi, Grigs

For such issues related to VS2003 please use an appropriate newsgroup, potentially one at http://msdn.microsoft.com/newsgroups

Thanks






Re: Visual C# General Debug vs Release

OmegaMan

To change the tack from what Figo said....try bringing it into VS2005 and see if the same happens Otherwise its the interop mapping or a cast that is getting in the way...heck try this

[DllImport("PCSHLL32.dll")] public static extern UInt32 hllapi(out UInt32 Func, StringBuilder sbData, out UInt32 Length, out UInt32 RetC);

to

[DllImport("PCSHLL32.dll")] public static extern int hllapi(out UInt32 Func, StringBuilder sbData, out UInt32 Length, out UInt32 RetC);







Re: Visual C# General Debug vs Release

Grigs

I have actually converted all of the UInt32's to int's and it still behaves the same. I will try the 2005 thing when I get a chance. But it won't work in deployment since not everyone (yet) has .Net 2.0.





Re: Visual C# General Debug vs Release

JocularJoe

> For such issues related to VS2003 please use an appropriate newsgroup

I find this a bit rich:

Newsgroups have been working well for many years.

And include .NET specific newsgroups.

So Microsoft creates not one but two forum sites for .NET (www.asp.net and this one).

And requires different logins / passwords for the two sites (!!!!!!)

As well as other login/passwords for other Microsoft sites (e.g. CodePlex)

All of which makes it difficult for .NET experts who want to help to find the right place to go

And now when someone asks a question here which isn't on the latest version, Microsoft tells them to go elsewhere!!!!

To the OP:

- Sorry I can't help with your problem.

- One thing you could try is to eliminate the differences between your Debug and Release build one by one to see which one is causing the problem. I.e. is it due to a conditional compilation constant that is defined in Debug but not Release mode, or because of the Optimize Code option





Re: Visual C# General Debug vs Release

OmegaMan

Grigs wrote:

I have actually converted all of the UInt32's to int's and it still behaves the same. I will try the 2005 thing when I get a chance. But it won't work in deployment since not everyone (yet) has .Net 2.0.



Again a long shot...but maybe create an old VB6 or C++ app and connect to it that way...it may shed some light on the call and returned values...

What does the unsupported code 10 actually mean to IBM