New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow different versions of xlwings to coexist (regarding dll) #743

Closed
sdementen opened this Issue Aug 23, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@sdementen
Contributor

sdementen commented Aug 23, 2017

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

This comment has been minimized.

Member

fzumstein commented Aug 23, 2017

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

This comment has been minimized.

Contributor

Colin-b commented Aug 23, 2017

@fzumstein

This comment has been minimized.

Member

fzumstein commented Aug 23, 2017

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

This comment has been minimized.

Contributor

Colin-b commented Aug 23, 2017

@sdementen

This comment has been minimized.

Contributor

sdementen commented Aug 23, 2017

@fzumstein

This comment has been minimized.

Member

fzumstein commented Aug 23, 2017

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

@sdementen

This comment has been minimized.

Contributor

sdementen commented Aug 24, 2017

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
  1. 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
  1. open both workbooks in the same excel
  2. 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

This comment has been minimized.

Member

fzumstein commented Aug 26, 2017

yes makes sense now, will look into it.

@sdementen

This comment has been minimized.

Contributor

sdementen commented Jan 6, 2018

Tx a lot Felix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment