-
-
Notifications
You must be signed in to change notification settings - Fork 276
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
Can not build/pack 32 bit add-in using dotnet CLI #610
Comments
With your project, I see the same problem. I don't know what the effect is on the output assembly if you compile with the specific platform identifier, but it breaks our ability to load the assembly as managed assembly for packing. Basically, your add-in assembly must be compiled as "AnyCPU". If there are platform specific native dependencies, and they are reflected correctly in the .deps.json file after the build, then the Excel-DNA packing should also handle them correctly. But making the project he way you have it with the explicit platforms is not something I can get to work. When targeting .NET 6 you also don't need to gather the
Then add the dependencies you need from there. Otherwise, you're outside venturing outside what I understand about the .NET builds. |
Hi @govert, with .net6 is this still valid for deploying excel-dna without locking? When I share the excel add-in with users and if it is opened by any user, I can not deploy a new version. Many files are locked. I am confused about how I should deploy to achieve the deployment that was possible with .netframework version. As you explain in the post above the reference dlls are inferred from the .deps.json in .net6 version so I have to put all dlls in the root directory. |
I think reloading under .NET 6 is still problematic, so I doubt the same plans will work. It sounds like you're trying to run the add-in from a network share, and update it there. I think that's going to be hard, and you might need to do the work to manage a local copy. |
Thank you for your help Govert! True, we are sharing from a network location. Do you know if excel-dna users are migrating from .net framework to .net6, or not? No issues with sharing from a network location in .net framework. Do you mean we should copy the add-in over to the user's machine, instead of using directly from the network? Thanks |
when building the 32 bit add-in using dotnet CLI
dotnet build -r win-x86 -c Release -p:EnvironmentName=PRD -p:Platform=x86 --sc false
I get the same error as in #329
could not be packed. Possibly a mixed assembly? (These are not supported yet.)
I do not get any errors when I create a 64 bit add-in
dotnet build -r win-x64 -c Release -p:EnvironmentName=PRD -p:Platform=x64 --sc false
And I can create a 32 bit build without error if I build through Visual Studio UI, but I need the .net CLI for deploying the project to production via Azure Devops.
you can replicate this error with an empty library project with these settings:
The text was updated successfully, but these errors were encountered: