• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 473 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

After installing CCS 5.2, can't compile redistributable dll/ax for customers in VisualStudio 2005

Mechi Fendel
Genius 4405 points
Other Parts Discussed in Thread: CODECOMPOSER

Hello,

After installing TI Code Composer on my computer (it happens on XP 32-bit and also Win7-64bit), I can't seem to compile dlls and distribute to customers.

I tried uninstalling and reinstalling VS 2005 (including Service Pack), but to no avail.

The dll works on the computer that has the Visual Studio C++ 2005 environment. It can be loaded and the application runs well.

On another computer, though, the dll cannot be loaded:

hDll = LoadLibrary(TEXT("MyProgram.dll"));

This line fails to load. hDll returns with NULL.

If I compile another project which yields MyProgram.ax - it cannot be registered on another computer (regsvr32.exe).

As I mentioned, the same exact source code, when compiled on a computer without the TI CodeComposer environment can be compiled (dll and ax) and also distributed to customers.

Please tell me how to fix this.

Thanks,

Mechi

  • 0
    TI__Guru*** 130875 points

    Hi Mechi,

    would you be able to describe in a bit more detail what you are experiencing.   Is the correct understanding you seem to think CCS blocks VS 2005?  This is very odd as I have not seen that on multiple pcs I have tried and CCS actually requires the 2005 redistributable package.

    What if you remove CCS? What might be different in the case where VS 2005 coexists and things work.

    Any further information would help.

    Best Regards,
    Lisa

  • 0 in reply to Lisa TI
    Genius 4405 points

    Hi - 

    I'll try uninstalling TI Composer and see if it makes a difference. I'll also try installing the Service Pack for VisualStudio 2005.

    It probably has something to do with the run-time of VC80 on the customer's machine. But why was there a change because of the TI CCS?

    Here is a screen shot of the WinSxS folder - and you can see the many versions of VC80 installed on my computer.

    Thanks,

    Mechi

  • 0 in reply to Mechi Fendel
    Genius 4405 points

    Hi,

    I uninstalled TI CCS and I reinstalled Service pack 1 for VS 2005. Still the problem persists.

    I think that there is some file that was changed when TI CCS was installed that changed the way my dll is compiled with VS 2005.

    Do you have any ideas?

    I'm going to uninstall VS 2005. If I install it anew, the problem I have with compiling for cuatomers will be resolved. But i won't be able to run TI CCS.

    I can then try installing TI CCS after VS 2005 is uninstalled. Then I can install VS 2005 and see if the probelm is fixed.

    What do you think?

    Why does this happen?

    Thanks,

    Mechi

  • 0 in reply to Mechi Fendel
    TI__Genius 16490 points

    Mechi,

    One explanation for this problem is as follows: VS2005 installs version "A" of the Microsoft redistributable libraries. When you install CCS, it installs version "B" (which is newer than version "A").  Now, when you compile a program with VS2005, VS uses the most recent version of the various installed redistributable libraries so you end up with a dependency on version "B".

    You can confirm what the dependencies are by using the Dependency Walker tool that comes with VS2005.

    You could solve this problem by installing the later Microsoft redistributable package on the PCs you want to run your binaries on. The installer can be downloaded from Microsoft, or you can grab the executable included with CCS. The CCS one is located at: <zip file extraction dir>/baserepo/vcredist_x86_2005.exe .

    You can also solve this problem by statically linking the RTS libs with your binary or by putting the dependent DLLs in the same folder as your application. There are probably other ways to solve this too. One Google reference you might find useful: here .