Publishing Alibre powered software and Integrations in an open source way.

[stepalibre]

I'm working on a separate application that interfaces with Alibre using AlibreX.dll. Not sure if that's technically an add-on or not.

I can't use AlibreRoot.Version because I don't know where Alibre's copy of AlibreX.dll is. If I use my own copy, it returns the wrong value.

Maybe I should ask the user to specify the install location of Alibre, then I can run RegisterCOMdlls.BAT and load AlibreX.dll from there?

This still apply, you use it to know what version you are running. You then decide what to do. Where you call it is different in your app but the idea is the same.

If you are working with an Add-on you can do something like:

public static void AddOnLoad(IntPtr hwnd, IAutomationHook pAutomationHook, IntPtr unused)
        {
            AlibreRoot = (IADRoot) pAutomationHook.Root;
            _parentWinHandle = hwnd;
             var version = AlibreRoot.Version.Replace("PRODUCTVERSION ", "");
             var versionarr = version.Split(',');
             var majorVersion = int.Parse(versionarr[0]);
             if (majorVersion < 27)
                 MessageBox.Show(Globals.AppName + "requires a newer version of Alibre Design", "Error");
          
           ....
        }

 

[LuminescentLoom]

Installers and running scripts/tools as admin is exactly for this purpose. If you don't have admin rights or your app is doing a lot under the hood it is easier and better to make an addon that start your application.

None of these solutions are suitable in my case. I'll just stick to requiring a specific version of Alibre for now and distributing AlibreX.dll with it so the only complicated part for the user will be running RegisterCOMdlls.BAT.

It's still a bit scary because if they try to use the wrong version of Alibre, it crashes my application. That's partly why I want to identify the version, but it seems there's no way to do that.

 

[stepalibre]

It's still a bit scary because if they try to use the wrong version of Alibre, it crashes my application. That's partly why I want to identify the version, but it seems there's no way to do that.

Why not ask them to pick the version of Alibre they want to use with your app first by launching a message box that ask them to pick V26, V27 or V28? Then handle each case all before any real code is run in an if or switch statement.

Or

Make V26, V27 or V28 shortcuts or bat files that pass the version to your app at runtime ( when they double click the shortcut) or something?

 

[NateLiquidGravity]

Skip all that. It assumes Alibre was installed in the default location.

Whenever Alibre is installed it automatically writes the install path into the registry. It's really simple if you know existing version numbers but not forward compatible because you can't predict a future version number.

The registry path starts with:
SOFTWARE\Alibre, Inc.\Alibre Design\
and then ends with the version build number. Check your registry to see the format.
The key you need with the install path is:
HomeDirectory

 

[stepalibre]

Skip all that. It assumes Alibre was installed in the default location.

Whenever Alibre is installed it automatically writes the install path into the registry. It's really simple if you know existing version numbers but not forward compatible because you can't predict a future version number.

The registry path starts with:
SOFTWARE\Alibre, Inc.\Alibre Design\
and then ends with the version build number. Check your registry to see the format.
The key you need with the install path is:
HomeDirectory

I do this in my scripts, along with other stuff.

 

[stepalibre]

Why not ask them to pick the version of Alibre they want to use with your app first by launching a message box that ask them to pick V26, V27 or V28? Then handle each case all before any real code is run in an if or switch statement.

Or

Make V26, V27 or V28 shortcuts or bat files that pass the version to your app at runtime ( when they double click the shortcut) or something?

Skip all that. It assumes Alibre was installed in the default location.

Whenever Alibre is installed it automatically writes the install path into the registry. It's really simple if you know existing version numbers but not forward compatible because you can't predict a future version number.

The registry path starts with:
SOFTWARE\Alibre, Inc.\Alibre Design\
and then ends with the version build number. Check your registry to see the format.
The key you need with the install path is:
HomeDirectory

This can all be done in installers and scripts.

NSIS Wiki

nsis.sourceforge.io

DeployMaster - Installation Builder - Setup Tool

DeployMaster is the no-nonsense software installer builder from Just Great Software. Deliver your applications to customers and prospects with a good first impression. Easy to use for both the developer and the end user.

www.deploymaster.com

Windows Installer Guide - Win32 apps

The Windows Installer Guide contains information of interest to authors of Windows Installer packages and users of the Windows Installer service.

learn.microsoft.com

 

[LuminescentLoom]

Why not ask them to pick the version of Alibre they want to use with your app first by launching a message box that ask them to pick V26, V27 or V28? Then handle each case all before any real code is run in an if or switch statement.

Or

Make V26, V27 or V28 shortcuts or bat files that pass the version to your app at runtime ( when they double click the shortcut) or something?

Then they have to choose both the version and the location it's installed at which seems redundant. Also, if they pick the wrong one, it'll crash. I was hoping to get this information from the registry or somewhere.

Maybe an easier way for the user is they choose the install location of Alibre and then my application runs RegisterCOMdlls.Bat from there as well as loading AlibreX.dll from there too and calling IADRoot.Version.

 

[stepalibre]

Then they have to choose both the version and the location it's installed at which seems redundant. Also, if they pick the wrong one, it'll crash. I was hoping to get this information from the registry or somewhere.

Maybe an easier way for the user is they choose the install location of Alibre and then my application runs RegisterCOMdlls.Bat from there as well as loading AlibreX.dll from there too and calling IADRoot.Version.

Please spell out in detail exactly what you want, best case, step by step.

 

[stepalibre]

Please spell out in detail exactly what you want, best case, step by step.

I can see if any of my solutions will work for you.

This test project is completely automated, but my build/deploy scripts aren't open source yet:

GitHub - Testbed-for-Alibre-Design/TestLocalRunnerRepo

Contribute to Testbed-for-Alibre-Design/TestLocalRunnerRepo development by creating an account on GitHub.

github.com

Workflow runs · Testbed-for-Alibre-Design/TestLocalRunnerRepo

Contribute to Testbed-for-Alibre-Design/TestLocalRunnerRepo development by creating an account on GitHub.

github.com

 

[LuminescentLoom]

Looks like finding it through the registry as @NateLiquidGravity suggested will be ideal, along with loading AlibreX.dll from there instead of distributing it myself or copying it to my application's directory.

 

[stepalibre]

Looks like finding it through the registry as @NateLiquidGravity suggested will be ideal, along with loading AlibreX.dll from there instead of distributing it myself or copying it to my application's directory.

That's what I was saying about dynamic code/programs.

It's possible to use the registry to find AlibreX for dynamic code/programs like IronPython programs to import AlibreX.dll.

 

[stepalibre]

One downside of the registry is cross platform development. I'm on a Mac and have Linux VMs. I'm developing more on Mac and Linux and I avoid the registry on windows at all cost, unless no other option . I use the registry in general as a fallback. I prefer portable and cross platform setups. Not your case, but good to know.

 

[bolsover]

Looks like finding it through the registry as @NateLiquidGravity suggested will be ideal, along with loading AlibreX.dll from there instead of distributing it myself or copying it to my application's directory.

For a stand alone application this is the correct method - and easy to do.
https://learn.microsoft.com/en-us/d...n32.registry.getvalue?view=netframework-4.8.1
The code is the same for other versions of .NET.

 

[LuminescentLoom]

One downside of the registry is cross platform development. I'm on a Mac and have Linux VMs. I'm developing more on Mac and Linux and I avoid the registry on windows at all cost, unless no other option . I use the registry in general as a fallback. I prefer portable and cross platform setups. Not your case, but good to know.

Yea, I wouldn't use the registry by choice. Even in Windows, applications aren't supposed to store their settings there. But it seems to have a place for this kind of "where even is it?" problems.

 

[stepalibre]

Yea, I wouldn't use the registry by choice. Even in Windows, applications aren't supposed to store their settings there. But it seems to have a place for this kind of "where even is it?" problems.

I prefer portable and self-contained software, the registry and appdata folders are notorious for poor use and lack of cleanup. I once had gigs of data leftover by Autodesk after uninstalling all their apps. There are tools that can help manage the registry but its still a pain. The registry and appdata is a good idea, but is often the cause of issues over time. I dont know if Win11 is better.

 

[LuminescentLoom]

I prefer portable and self-contained software, the registry and appdata folders are notorious for poor use and lack of cleanup. I once had gigs of data leftover by Autodesk after uninstalling all their apps. There are tools that can help manage the registry but its still a pain. The registry and appdata is a good idea, but is often the cause of issues over time. I dont know if Win11 is better.

Fully agree. It's just there are use cases where self-contained doesn't work and at least we have appdata instead of applications sprinkling .ini files all over the place, even in the root directory.