Re: About protected memory in COM(in-process)
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sun, 14 Dec 2008 03:38:23 -0500
See below...
On Mon, 08 Dec 2008 17:46:59 GMT, "Tony Johansson" <johansson.andersson@xxxxxxxxx> wrote:
Hello!****
For several years ago an in-process COM dll was deleloped using ATL/C++/MFC
This in-process COM DLL was initially used from VB6 and it has worked ever
since then and still works today
without any kind of problem.
It has never ever been any kind of problems with this COM dll.
For about 7 month ago a C# asp.net webb application was deloped where this
in-process COM DLL was used.
When this C# asp.net webb was finished and put into test where the COM dll
was called error began to appear.
Not every time but far too often. It wasn't reliable.
The errors that appear was the protected memory.
Now to my question:
How is possible that the exact same COM dll work just perfectly when being
run under windows VB6 and not from
C# asp.net webb application. One major differens here is that they are being
run under different environment.
In the second case when a C# asp.net webb application is running it's the
Internet Information Service(IIS) that is running the code.
So for me it sounds strange that there could be programming errors in the
COM dll when the COM dll works
perfect when being called from VB6.
No. It could be that the COM DLL made some unwarranted assumption, which it should not
have made, and therefore when called from C#, this assumption is no longer valid, and the
bug which has been there since day one is now visible. The assumption that the code was
"always correct" is unjustified.
****
****
Could it be as simple as it's not fully supported or not recommended to use
in-process COM dll from C# asp.net webb application.
No, but it is always possible that an erroneous COM component has a bug that VB6 never
tickled. For example, a VARIANT type that assumed that only one kind of VARIANT was being
passed (and now a different VARIANT is passed) would be one possible guess. Another is
the situation where the test was of the form "if(variant-type == some_one_type) {...} else
{...} where the assumption is that only two possible variant types could ever be passed,
instead of writing the correct code, "if(variant-type == some_one_type) {...} else
if(variant-type == other_possible_type) {...} else {...error code here...}.
Lacking anything useful about the interface, such as the parameter types, the nature of
the error, or anything else that might even HINT at what is going wrong, makes any kind of
diagnosis impossible. All you've said is "I have a software component that was tested in
exactly one limited situation, is now running in a different situation, and for some
reason it doesn't work. What did I do wrong?" The only obvious guesses are "It wasn't
really tested" and "it was always wrong, you just never noticed before", but if you want
more help than that, a LOT more information has to appear here.
****
****
I mean that if the COM dll had some error it would appear when being used
from an application developed in VB6
This is about as silly an assumption as assuming that it is error-free. OF COURSE it
could have an error that would never be seen when called from VB6, because VB6 might never
have been able to create the situation that tickled the error. C#, however, could still
obey the interface specifications, create yet another case, THAT WAS SUPPOSED TO BE
HANDLED but wasn't, and consequently uncover a defect that was never tested for. It
doesn't mean the code was correct, only that the situation that tickled the bug had not
arisen in the past. Why would you suspect the code is correct, or even thoroughly tested?
****
****
Nothing makes sense in this difficult question.
It seems a not-very-difficult question. There's something wrong. Track it down. Without
giving us the slightest hint about what the code is, how it is was called in VB6, how it
is called in C#, or anything else that could be remotely useful in diagnosing the problem,
what exactly do you expect us to do?
****
****
Can somebode give a comment about this.
The code is probably wrong. Fix it.
If you want more detailed advice, you have to say something about the code other than it
"doesn't work"
joe
****
Joseph M. Newcomer [MVP]
//Tony
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- About protected memory in COM(in-process)
- From: Tony Johansson
- About protected memory in COM(in-process)
- Prev by Date: Re: confused by exception handling in VC 2008
- Next by Date: Re: About protected memory in COM(in-process)
- Previous by thread: Re: About protected memory in COM(in-process)
- Next by thread: Common File Dialog and Extensions
- Index(es):
Relevant Pages
|
