Allow different versions of xlwings to coexist (regarding dll)

[sdementen]

Currently, having workbooks using different versions of xlwings is not possible due to xlwingsNN.dll that are different per versions but share the same name (error = "BAD DLL convention...")
Could it be possible to version the dll so that it is possible to use different workbooks with each their own virtual/conda env using different versions of xlwings ?
versioning in the sense: xlwings32.dll => xlwings32.0.10.4.dll
Would this solve the issue ? would this create other issues ?

[fzumstein]

If you set your interpreter to the path of a virtual/conda env, it should be using the dlls that are part of that environment so it should work without renaming. Or are you doing sth differently?

[Colin-b]

Xlwings is used in addition to another addin relying on xlwings and if the version of xlwings differs this issue occurs (even in different venv of course).

…

On Wed, Aug 23, 2017, 21:11 Felix Zumstein ***@***.***> wrote: If you set your interpreter to the path of a virtual/conda env, it should be using the dlls that are part of that environment so it should work without renaming. Or are you doing sth differently? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHPX_cr-cY3gRQ5AzguSDwfHAaEpfNmNks5sbHlXgaJpZM4O_tif> .

[fzumstein]

what stops you from upgrading xlwings across the board? I don't think there were a lot of breaking changes from 0.10 to 0.11

[Colin-b]

It is indeed planned and we have a workaround for now but I think it would be nice to be able to use different version of xlwings addin side by side.

…

On Wed, Aug 23, 2017, 21:54 Felix Zumstein ***@***.***> wrote: what stops you from upgrading xlwings across the board? I don't think there were a lot of breaking changes from 0.10 to 0.11 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHPX_d5nUhtt-GK-iUq3Fu1U7N0AMTg0ks5sbIOMgaJpZM4O_tif> .

[sdementen]

Moreover, in previous versions the xlwings module was in the workbook. Hence i you have lot of copies of the workbook that you want to be able to reopen occasionally but are not worth to migrate, it should be possible to isolate xlwings, i.e. the loaded dll as the rest (vba module and Python env/code) is already isolated, across workbooks. Sent from my Samsung Galaxy smartphone.

-------- Original message -------- From: Colin Bounouar <notifications@github.com> Date: 8/23/17 21:59 (GMT+01:00) To: ZoomerAnalytics/xlwings <xlwings@noreply.github.com> Cc: "de Menten Sébastien (Electrabel)" <sebastien.dementen@engie.com>, Author <author@noreply.github.com> Subject: Re: [ZoomerAnalytics/xlwings] Allow different versions of xlwings to coexist (regarding dll) (#743) It is indeed planned and we have a workaround for now but I think it would be nice to be able to use different version of xlwings addin side by side.

On Wed, Aug 23, 2017, 21:54 Felix Zumstein ***@***.***> wrote: what stops you from upgrading xlwings across the board? I don't think there were a lot of breaking changes from 0.10 to 0.11 - You are receiving this because you commented. Reply to this email directly, view it on GitHub <#743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHPX_d5nUhtt-GK-iUq3Fu1U7N0AMTg0ks5sbIOMgaJpZM4O_tif> .

- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#743 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABPpdvc4foO3B2InNyM1n-DLAC4gXZ2pks5sbIShgaJpZM4O_tif>. ENGIE Mail Disclaimer: http://www.engie.com/disclaimer/

[fzumstein]

I have a hard time to follow. can you describe in details the simplest setup that leads to a conflict?

[sdementen]

To reproduce the issue:

1. create a workbook with version 0.10 of xlwings:

• create a conda env with xlwings=0.10
• create the workbook with the proper xlwings.bas and pointing to the conda env

2. create another workbook with version 0.11 of xlwings:

• create a conda env with xlwings=0.11
• create the workbook with the proper xlwings.bas and pointing to the conda env

3. open both workbooks in the same excel
4. run in each workbook an UDF
   ==> the first workbook to run the UDF. It loads the xlwingsNN.dll from its conda env path and executes properly the UDF
   ==> the second workbook to run the UDF and shows the DLL error message (bad calling convention). I think Excel keeps a mapping of the name of the DLL (xlwingsNN.dll ... without the full path) to the DLL and therefore doesn't load the new xlwingsNN.dll from its conda env path and so fails with the message... a bit like the caching of modules in python. But I could not find any info on this on google.

So, my conclusion (may be wrong) is that we need to differentiate the name of the DLL per version to avoid the issue with Excel "caching" the DLL by name.

I have tested this fix by renaming both the dll in the folder and the dll in the xlwings.bas module and it solves the issue.

Is it clearer ?

[fzumstein]

yes makes sense now, will look into it.

[sdementen]

Tx a lot Felix!