Dot Net Wrapper DLL Compatability With New OCX

Question

2.33/5 (3 votes)

See more:

I wrote an OCX to communicate with an USB device in VB6. I then wrote a Visual Studio 2005 .net application that used the OCX. Then I made a small change to the OCX, with binary compatibility on. The new OCX works fine with VB6 programs compiled with the older OCX, but not with .net programs compiled with the older OCX. I suspect the problem is with the wrapper DLLs that .net creates for using activex components. I have upgraded OCXs before and never run into this problem, although a customer recently reported a problem like this, but we were not able to recreate his problem until now. I believe that rebuilding the .net program with the new OCX would resolve the problem, but it is not piratical to rebuild all of our .net programs every time we upgrade an OCX.

Has anyone else run into this problem, and did you find a solution?

Thanks,
Mike Fryer

Posted 15-Feb-11 15:18pm

mikeef

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2011-02-15T15:29:00

Solution 1

It is very practical to rebuild everything you have a source code for! Is your build is done correctly, you always have a possibility to choose between full and incremental build. One of the biggest misconception in development is "don't re-build what works". This is simply unsafe and, at the same time, don't save you any development time. I know people who simply lost part of their source code or the ability to support it due to this simple mistake.

If you disagree, to me it would look like you have no sound versioning/deployment/testing strategy yet. As you gain experience, you will get to the same conclusion sooner or later, but better learn on mistakes of someone else, not on your own.

You need to have one-click build project, versioning strategy (as simple as you can afford, my best advice: identical version of all components (if possible, of course)), revision control and regression testing.

—SA

Posted 15-Feb-11 15:29pm

Sergey Alexandrovich Kryukov

Comments

mikeef 15-Feb-11 21:37pm

We use these OCXs in a lot of programs as do our customers. I am not going to rebuild and re-release 50 different applications just to make a change to an OCX, nor would we require our customers to rebuild their applications. The OCXs should be compatible, and always have been in the past. And If rebuilding all the applications was feasible, I wouldn't be asking for help, I would just do it.

Sergey Alexandrovich Kryukov 15-Feb-11 22:07pm

That is up to you, but not a valid reason to vote like this.
Nothing usually prevent you from updating of the whole product.
There is a schema to make a product patchable and send installable patches. You need to learn the techniques if you want to argue.

Will you please tell why you find rebuild non-feasible?

--SA

mikeef 16-Feb-11 10:38am

I stated that I knew that rebuilding would solve it, so telling me to rebuild isn't answering my question. 11 OCXs and hundreds of applications plus all the application written by our customers, your suggestion turns a few hours of work into weeks of work. If you have any help regarding my actual problem, I would love to hear it, but I no desire to debate the feasibility of rebuilding.

Sergey Alexandrovich Kryukov 16-Feb-11 14:13pm

You're pretty rude buddy; and weeks of your work does not justify it. People work a lot more.
You do not criticize my answer based on any rational argument; you simple say "I know better because I worked a long time on it". This is not convincing; who knows about you real experience?
I still think you should listed to my advice. I seriously doubt you're doing right thing.
But this is up to you, of course, nothing to discuss here.

--SA

Manfred Rudolf Bihy · Answer 2 · 2011-02-17T22:58:00

Solution 2

In my opinion all that needs to be rebuild is the OCX wrapper dll in a small project. Then build a small installer that will register the changed OCX and patch your applications.
Is that a viable option?

Cheers!

Posted 17-Feb-11 22:58pm

Manfred Rudolf Bihy

mikeef · Answer 3 · 2011-02-22T05:45:00

I replaced the original OCX, from 2002, in the compat folder with the previous version, 2008, that did not have any problems and then rebuilt the OCX. It worked with all of the .net application I have tested it with. I don't really understand why, I was just trying anything I could think of. If anyone can explain why this worked, I would like to understand it.

Thanks to those who tried to help.