Where to install DLL that automatically creates INI file?

[paulg4ije]

My project uses a third-party dll which automatically creates an ini file in the same folder as the dll. My project then needs to read from and write to that ini file, so although my app's folder in ProgramFiles would be the ideal place for the dll, I think this could give permission issues when I try to use the ini file. I can of course choose where to install the dll, but it must be to a fixed path as I have to declare functions like this:

Public Declare Function mmsGetVersion Lib "SSTVENG.DLL" () As Integer

As I understand it, I cannot use a variable to specify the path to the dll, so although I can hard-code a longer path - "c:\ProgramData\MyApp\sstveng.dll" for example, I cannot use something like: Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) to use the ProgramData folder. If I hard-code the path, my app would not work on Windows XP, unless I create a ProgramData folder in the root of the users c: drive. Is there an elegant solution to this dilemma?

[paulg4ije]

Just to clarify, the dll also needs access to the ini file and expects to find it in the same folder as the dll. There isn't a way to tell the dll code to look elsewhere.

I'm beginning to think a hard-coded path to ProgramData might be the only way to solve this, unless something like this can be made to work:

Dim myPath as string = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) & "\MyApp\sstveng.dll"

Public Declare Function mmsGetVersion Lib myPath () As Integer

But that declaration does not work with a variable in it; it must have the path hard-coded. Any thoughts?

[NeedSomeAnswers]

Why cant you use -

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

It should be O/S independent, on an XP machine it should return you the application data folder on Win 7 / 8 it should return the ProgramData folder.

Have you checked ?

[paulg4ije]

Because you can't use a variable in a "Declare Function" definition. Did you see my second post?

[NeedSomeAnswers]

Sorry your right i missed your point.

Soooo my next question is why do you need to specify the path? As in all examples i have seen do not, they just use the dll name.

I take it this is a com dll?, is it registered?

[paulg4ije]

Unfortunately the DLL wont register:

"The module “sstveng.dll” was loaded but the entry-point DllRegisterServer was not found. Make sure that “sstveng.dll” is a valid DLL or OCX file and then try again."

It all works fine when referenced by path. It's an integral part of my project - there's nothing else like it - so I will have to work around this issue somehow, even if it requires a bit of a cludge ;-)

[techgnome]

When you don't include a path for an API, it will look in the app directory first, followed by the current directory (which may or may not be the same as the application's path), followed by the paths that are in the PATH environment variable. IF you go out to a command prompt and type "path" ... it will tell you the contents of it... So as long as your DLL is in one of those paths, it should be discoverable.

OK, so that solves the problem of the pathing for the declare. Now the question that remains is what to do about where to put it. If you're using an installer you can then install it where you want, then the installer should be able to add that path to the PATH environment.

Just out of curiosity, is there a reason for using an INI file rather than the application's config file that's given to you?

-tg

[paulg4ije]

Just out of curiosity, is there a reason for using an INI file rather than the application's config file that's given to you?

-tg

As I said, the DLL creates the INI automatically. The DLL then requires on-going access to the INI. My project also needs to read and possibly write some to some of the parameters in the INI. I have little choice in the matter.

I would of course like to just include the DLL in my program folder, but as the INI will also then be created in the program folder, I am assuming UAC issues will occur when my app tries to write to the INI file.

[NeedSomeAnswers]

One thing you seemed to miss from TG's post was this

it will look in the app directory first ...followed by the paths that are in the PATH environment variable

You do know you can edit this list right? here is a link

In fact TG even said -

If you're using an installer you can then install it where you want, then the installer should be able to add that path to the PATH environment.

The Installer has its own variables for things like App Data, and so it will work out the full path for it for you dependent on the O/S.

You can then save this into the PATH environment variable, and then your dll should work without a path for the function.

Or at least that is what TG was saying

this is new to me too

[paulg4ije]

OK. I'll look into the PATH environment and write some test code.

Thanks for your help.