Unable to load DLL 'tm1api.dll': The specified module could

[shockwave]

Hi Guys,

Anyone seen this error when using VWD2005? "Unable to load DLL 'tm1api.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"
I cannot for the life of me, reference API objects contained in TM1. The only thing I can think of is that the installation was not done on the default drive being the c drive. In the notes it makes referece to to this which I think i have done correctly:

Setting a Path to the DLLs

I have done the following:

1. Created a folder and dropped the application and all the dll files in C:\Applix\integra\bin\ per the notes"The following procedure assumes that you accepted the default settings
during the installation, and that the TM1 API .dll files are in
C:\Applix\integra\bin."

2. I have tond the compiler to look for .dll files in "environmental variables" however it does mention that this is for NT server. Does it matter that I am using my own pc??
>variable = "path"
>value = "C:\Applix\integra\bin\;"

When i try to run my webpage, i now get the following error: "Unable to load DLL 'tm1api.dll': The operating system cannot run . (Exception from HRESULT: 0x800700B6)"

Out of ideas for the moment, has anyone encountered this issue b4??

Cheers

Shock

[Alan Kirk]

Anyone seen this error when using VWD2005? "Unable to load DLL 'tm1api.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"
I cannot for the life of me, reference API objects contained in TM1. The only thing I can think of is that the installation was not done on the default drive being the c drive. In the notes it makes referece to to this which I think i have done correctly:

Which operating system?
Are you running as Administrator?
If not, are you sure that the .dll is registered?

[shockwave]

Hi Allan,

Running it in "Microsoft Windows XP Professsional version 2002". I also have admin rights to the machine ( my workstation).

Cheers

Shock

[shockwave]

Hi Alan,

Missed the last point you made.How do i make sure the .dll is registered? Still learning the ropes.

Cheers

Shock

[shockwave]

Hi Alan,

I found something about "registering a dll file". Found nothing in the TM1 documentation that mentioned this.

http://www.tech-faq.com/register-dll.shtml


In the example they provide, would I use the following code to register each dll by using the following line of code in run dialog box?:
Regsvr32 "C:\Applix\integra\bin\tm1api.dll"

Excuse my noobness, wont be able to test this till I get back into work but am keen on a reponse to see whether this is correct, b4 I screw something up.

Cheers

Shock

[Alan Kirk]

I found something about "registering a dll file". Found nothing in the TM1 documentation that mentioned this.

http://www.tech-faq.com/register-dll.shtml

In the example they provide, would I use the following code to register each dll by using the following line of code in run dialog box?:
Regsvr32 "C:\Applix\integra\bin\tm1api.dll"

Excuse my noobness, wont be able to test this till I get back into work but am keen on a reponse to see whether this is correct, b4 I screw something up.

Sorry, I hit a major busy patch yesterday afternoon that will run into this morning.

The last item was more of a random thought; the Admin access was the more important one. I've never personally had to worry about registering any of the TM1 .dlls, but I run as Admin. I know that we've had problems with some of the client libraries no longer taking care of registering themselves since our IT department stopped giving users Power User access, and also the problem that you mentioned did sound symptomatic of a registration issue. (Though not having come across it before, that was just a guess.)

regsvr32 is indeed what's used to register most libraries (though regasm is apparently used to register .NET assemblies, though I haven't gotten into .NET enough to have to worry about that yet), HOWEVER that doesn't seem to work on that particular library since it can't find the DLLRegisterServer entry point.

I'll take a look through my reference notes later today, but unfortunately I can't test this further since I don't use VWD. (That would require someone to put a bazooka to my head and pry Dreamweaver CS3 out of my cold, dead hands.) Hopefully someone else has some ideas.

[Mike Cowie]

Just a quick note on DLL registering and some of the issues you bring up (Sorry I can't respond to more of this post right now, but will try to find more time over the next few days if you're still stuck):

Registering DLLs is only necessary for COM DLLs, which the TM1 API DLLs are not. A really rough explanation is that COM DLLs have various class/object ID's that need to get entered in the Windows registry so that you can, from VB/VBA, for example, establish a reference and refer to them by name:

Code: Select all

Dim MyWorkbook as [b][u]Excel.Workbook[/u][/b]

Regsvr32 is the command used to do this registration process for COM DLLs. COM DLLs can cause you grief if you have more than one version of the same DLL registered and your app is picking up an older/newer version you aren't expecting.

Win32 DLLs (which is what the TM1 API DLLs basically are) on the other hand contain a set of functions that you can call from your code if you know the function declarations that are used/required (which you do for the TM1 API). Those DLLs get loaded into memory when you're using them and the issue you can run into with these, unlike COM DLLs, is where your application finds the TM1 API dlls. If, for example, you have copies of the TM1 API dlls in the same folder as the application you're developing/running, your application will be able to find the DLLs and function calls will succeed. Your application will try to find the TM1 API dlls in one of the following places described in this article: http://msdn.microsoft.com/en-us/library/ms682586.aspx
I think the article mentions that you can also explicitly load a Win32 DLL into memory to "find" it more directly, though I haven't really tried that, personally - I usually just make sure it's in the path.

NOTE: If you are missing ANY of the TM1 API files, you will get the same "File not found: TM1API.DLL" or the error you mention here. That's because the entry point for all function calls is TM1API.DLL. The set of TM1 API files is the following (going from memory):

• TM1API.DLL
• TM1SIP.DLL
• TM1LIB.DLL
• LIBEAY32.DLL (TM1 9.1 and higher)
• SSLEAY32.DLL (TM1 9.1 and higher)
• The entire \ssl subfolder in your TM1 bin directory (TM1 9.1 and higher)

The API documentation still neglects to mention these last 3 items, I believe. AND, in TM1 9.1 and higher you may encounter problems if LIBEAY32.DLL or SSLEAY32.DLL are found elsewhere in the path BEFORE your TM1 API files are found. LIBEAY32.DLL and SSLEAY32.DLL are open source DLLs, which means other applications installed on your machine may contain different versions of the same DLLs. If you run into this problem you may need to put the TM1 API folder further toward the front of your PATH or explicitly load the DLLs from a specific location.

Hope that helps and sorry again for the rushed response.

Regards,
Mike

[shockwave]

Thanks for the education guys. Going to have a look at a couple of those suggestions and try a reinstall of the client again. I will post my findings in this thread.

Appreciate the help.

Cheers

Shock

[jimshen]

Just a quick note on DLL registering and some of the issues you bring up (Sorry I can't respond to more of this post right now, but will try to find more time over the next few days if you're still stuck):

Registering DLLs is only necessary for COM DLLs, which the TM1 API DLLs are not. A really rough explanation is that COM DLLs have various class/object ID's that need to get entered in the Windows registry so that you can, from VB/VBA, for example, establish a reference and refer to them by name:

Code: Select all

Dim MyWorkbook as [b][u]Excel.Workbook[/u][/b]

Regsvr32 is the command used to do this registration process for COM DLLs. COM DLLs can cause you grief if you have more than one version of the same DLL registered and your app is picking up an older/newer version you aren't expecting.

Win32 DLLs (which is what the TM1 API DLLs basically are) on the other hand contain a set of functions that you can call from your code if you know the function declarations that are used/required (which you do for the TM1 API). Those DLLs get loaded into memory when you're using them and the issue you can run into with these, unlike COM DLLs, is where your application finds the TM1 API dlls. If, for example, you have copies of the TM1 API dlls in the same folder as the application you're developing/running, your application will be able to find the DLLs and function calls will succeed. Your application will try to find the TM1 API dlls in one of the following places described in this article: http://msdn.microsoft.com/en-us/library/ms682586.aspx
I think the article mentions that you can also explicitly load a Win32 DLL into memory to "find" it more directly, though I haven't really tried that, personally - I usually just make sure it's in the path.

NOTE: If you are missing ANY of the TM1 API files, you will get the same "File not found: TM1API.DLL" or the error you mention here. That's because the entry point for all function calls is TM1API.DLL. The set of TM1 API files is the following (going from memory):

• TM1API.DLL
• TM1SIP.DLL
• TM1LIB.DLL
• LIBEAY32.DLL (TM1 9.1 and higher)
• SSLEAY32.DLL (TM1 9.1 and higher)
• The entire \ssl subfolder in your TM1 bin directory (TM1 9.1 and higher)

The API documentation still neglects to mention these last 3 items, I believe. AND, in TM1 9.1 and higher you may encounter problems if LIBEAY32.DLL or SSLEAY32.DLL are found elsewhere in the path BEFORE your TM1 API files are found. LIBEAY32.DLL and SSLEAY32.DLL are open source DLLs, which means other applications installed on your machine may contain different versions of the same DLLs. If you run into this problem you may need to put the TM1 API folder further toward the front of your PATH or explicitly load the DLLs from a specific location.

Hope that helps and sorry again for the rushed response.

Regards,
Mike

Hi Mike,

Very good trainning material.

I simply follow TM1 API document to update PATH. It works but not sure why before reading your explannation.

Further to the API.DLL access, I had the problem with the error message says "Attempted to read of write protected memory. This is ofter na indication that other memory is corrupt."

Even I tried to shifted order of PATH, the problem still there.

When I stepped each statement, TM1SystemOpen gives me 19 digits rather than 9, and error stops at TM1ValString.

With same statement, works fine in MS Access VBA. I remember it works fine in TM1 version 9.0 plus.

It might be hard for you to know why in my environment, but is it possible for you to give a few working codes to start in VWD 2005 Expression, and let me know the TM1 version then I can replicate so can find out why causes the proplem?

Thank you very much.

Jim

[Mike Cowie]

Further to the API.DLL access, I had the problem with the error message says "Attempted to read of write protected memory. This is ofter na indication that other memory is corrupt."

Even I tried to shifted order of PATH, the problem still there.

When I stepped each statement, TM1SystemOpen gives me 19 digits rather than 9, and error stops at TM1ValString.

With same statement, works fine in MS Access VBA. I remember it works fine in TM1 version 9.0 plus.

It might be hard for you to know why in my environment, but is it possible for you to give a few working codes to start in VWD 2005 Expression, and let me know the TM1 version then I can replicate so can find out why causes the proplem?

Hi Jim,

I haven't had a chance to test out what you're trying to do here and in your other thread/post yet, but one thing you should be aware of if you're developing in a .NET environment with the C/VB TM1 API is that you may not be able to copy the TM1 API VB declarations, for example, without some modification/conversion. The VB declarations were originally developed for VB6, where a Long, for example, was a 32-bit integer. In VB.NET, a Long is a 64-bit integer. So, the following API declaration:

Code: Select all

Declare Function TM1SystemOpen Lib "tm1api.dll" () As Long

In VWD 2005 means something very different. I believe to have a function like this work/return a valid 32-bit integer you would need to change the declaration to:

Code: Select all

Declare Function TM1SystemOpen Lib "tm1api.dll" () As Integer

I haven't had a chance to try this myself, but there is are many "conversion" documents out there that might help point you in the right direction. Here's one I found on a quick search: http://msdn.microsoft.com/en-us/library/aa260644.aspx. You would have to do similar conversions for your other TM1 API function declarations.

So, to summarize, what I think is happening to you in VWD 2005 is that you're using VB6 declarations, unchanged, in VB.NET and as a result the actual types of variables you are passing do not match what the TM1 API functions are expecting.

Regards,
Mike

[shockwave]

HI Mike,

The last 2 dll's you mention:

# LIBEAY32.DLL (TM1 9.1 and higher)
# SSLEAY32.DLL (TM1 9.1 and higher)

Where can these be found, and do I just drop it in the same directory as the other dlls mentioned as well?

Thanks again

Shock

[Mike Cowie]

The last 2 dll's you mention:

# LIBEAY32.DLL (TM1 9.1 and higher)
# SSLEAY32.DLL (TM1 9.1 and higher)

Where can these be found, and do I just drop it in the same directory as the other dlls mentioned as well?

Hi Shock,

From your earlier posting, you say your API files are in:

C:\Applix\integra\bin

Based on that path, I don't think you're using TM1 9.1 or higher, which is when these DLLs came into play. I suspect you're on some earlier version of TM1 8, in which case you don't need to worry about them because they aren't relevant to those versions.

Regards,
Mike

[shockwave]

Hi Mike,

Currently using 9.1.3. I dumped the .dlls in a folder suggested from the notes. Was clutching at straws to make this work.

Can you kindly provide a link to those dlls you mention?

Thanks again

Shock

[shockwave]

Ignore last post. I found the files.

[jimshen]

Hi Jim,

I haven't had a chance to test out what you're trying to do here and in your other thread/post yet, but one thing you should be aware of if you're developing in a .NET environment with the C/VB TM1 API is that you may not be able to copy the TM1 API VB declarations, for example, without some modification/conversion. The VB declarations were originally developed for VB6, where a Long, for example, was a 32-bit integer. In VB.NET, a Long is a 64-bit integer. So, the following API declaration:

Code: Select all

Declare Function TM1SystemOpen Lib "tm1api.dll" () As Long

In VWD 2005 means something very different. I believe to have a function like this work/return a valid 32-bit integer you would need to change the declaration to:

Code: Select all

Declare Function TM1SystemOpen Lib "tm1api.dll" () As Integer

I haven't had a chance to try this myself, but there is are many "conversion" documents out there that might help point you in the right direction. Here's one I found on a quick search: http://msdn.microsoft.com/en-us/library/aa260644.aspx. You would have to do similar conversions for your other TM1 API function declarations.

So, to summarize, what I think is happening to you in VWD 2005 is that you're using VB6 declarations, unchanged, in VB.NET and as a result the actual types of variables you are passing do not match what the TM1 API functions are expecting.

Regards,
Mike

Hi Mike,

I've resolved the problem under your indication.

Thank you very much for that.

Jim

[zameelarif]

Hi Guys

I am trying out TM1 API programming using TM1 9.1.4 and Visual studio 6.0 .
I have added the dll's to the environment path variable, also copied the dll's to the folder(infact all the dll's from the bin) where i have saved the vb project.
I have done the TM1 and VB installation in their respective folders inside Program Files (hope that is not an issue)
I imported the tm1api.bas file as advised in the API guide and started working on my first API screen, but when i try to compile this is the error i get , Run-Time error '48' , File not found: tm1api.dll

I tried registering the dll's , but then it says entry point not found. If i try using the reference in VB , it says cannot add this dll.

I have totally hit an roadblock.... any help will be much appreciated.

Regards
Zameel

[Mike Cowie]

I have added the dll's to the environment path variable, also copied the dll's to the folder(infact all the dll's from the bin) where i have saved the vb project.

When you say you've copied the DLL's, which ones are you referring to? As you'll see from earlier in this thread, the TM1 API manual neglects to mention several supporting TM1 API files and an additional folder that are required starting with TM1 9.1 (in other words, the same files are also needed in TM1 9.4). Failure to include any one of those will result in the "File not found: TM1API.DLL" message.

As far as adding files to the environment path variable, you should only need to add the folder that contains the API files to the PATH variable - usually that's the Bin folder where the TM1 program files were installed. Just adding the folder to the path should be enough - there's no need to explicitly reference each file in the path (I don't believe that will even work). You should also not need to copy the files into the folder with your VB project - it should certainly work if you get every necessary file/folder copied, but it is redundant if you've already referenced another folder using the PATH environment variable. And, as you use new TM1 versions, you can get tripped up if you have multiple copies of TM1 API files around.

I tried registering the dll's , but then it says entry point not found. If i try using the reference in VB , it says cannot add this dll.

The TM1 API files are not COM dlls, which are the kind of DLLs that can be registered. Registering TM1 API files or referencing them is meaningless - the way you access their functionality is through the TM1API.BAS function declarations that you've already imported, which provide the necessary entry point information for VB. Once you get the path issues sorted out you should be in much better shape.

Regards,
Mike

[zameelarif]

Hi Mike... thanks for your inputs... ya i read some of the above posts...when i said all the dll's , i meant all the dll's in the Bin folder to the folder where i was developing my VB project..
Now i have uninstall TM1 and Visual studio, also remove the path reference... and then probably try with a fresh installation... and as u suggested get my path settings rite ?
do you think there might be a compatibality issue between TM1 9.1.4 and VS 6.0.

[Mike Cowie]

...when i said all the dll's , i meant all the dll's in the Bin folder to the folder where i was developing my VB project..
Now i have uninstall TM1 and Visual studio, also remove the path reference... and then probably try with a fresh installation... and as u suggested get my path settings rite ?
do you think there might be a compatibality issue between TM1 9.1.4 and VS 6.0.

Did you also copy over the entire contents of the ssl subfolder? You need that, too. There should be no compatibility issues with TM1 9.1.4 and VS 6.0 based on what you're talking about.

One other thing that can happen as well with TM1 9.1 and above... search for the open source DLLs that are part of the TM1 API file set (LIBEAY32.DLL and SSLEAY32.DLL) on your machine. If you see them in another location (like C:\Windows\System32) you may need to play around with Path settings to make sure those in the \Bin folder get picked up first or update the other copies to the version in your \Bin folder (assuming it doesn't break whatever other application(s) installed those DLLs). If I remember correctly, it seems like some Dell machines had some pre-installed utility software that installed/used the same open source DLLs.

Regards,
Mike

[zameelarif]

Hi Mike

I have checked my system and the open source dlls are available in the C:\windows\system32 and in TM1 bin folder.The size of these files are different I am attaching a screen shot of the search result. Will it be ok for me to overwrite the files from windows directory to the TM1 bin directory.


Thanks and Regards
Zameel