Could not load file or assembly System.Runtime.Metadata

[Michael Goldsworth]

Hi, I'm new to Excel-DNA and the group, just starting with the basic project from https://excel-dna.net/.

After following the steps line by line to just start with the SayHello function (including adding the package reference to csproj) and attempting to build, I immediately get the following errors:

Severity Code Description Project File Line Suppression State
Error DNA-148729608 Could not load file or assembly 'System.Reflection.Metadata, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. OPC Toolkit Excel Add-In 1

Severity Code Description Project File Line Suppression State
Error DNA-148729608 System.IO.FileNotFoundException: Could not load file or assembly 'System.Reflection.Metadata, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Reflection.Metadata, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at ExcelDna.PackedResources.ExcelDnaPack.IsAssembly(String path, Boolean& isPE)
   at ExcelDna.PackedResources.ExcelDnaPack.FindManagedDeps(String dnaPath, String outputBitness)
   at ExcelDna.PackedResources.ExcelDnaPack.PackDnaLibrary(String dnaPath, Byte[] dnaContent, String dnaDirectory, ResourceUpdater ru, Boolean compress, Boolean multithreading, List`1 filesToPublish, Boolean packManagedDependencies, String[] dependenciesToExcludeParam, String outputBitness, IBuildLogger buildLogger)
   at ExcelDna.PackedResources.ExcelDnaPack.Pack(String dnaPath, String xllOutputPathParam, Boolean compress, Boolean multithreading, Boolean overwrite, String usageInfo, List`1 filesToPublish, Boolean packNativeLibraryDependencies, Boolean packManagedDependencies, String excludeDependencies, Boolean useManagedResourceResolver, String outputBitness, IBuildLogger buildLogger)
   at ExcelDna.AddIn.Tasks.PackExcelAddIn.Execute()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
OPC Toolkit Excel Add-In 1

The output suggests this is a dependency within ExcelDna itself. After looking online, some suggestions were to set the property 'Copy Local' for the package references ... but this exists no where in Visual Studio 2022 17.1.6 that I can find. This does not appear to be an option any longer.

Has anyone else hit this or have any idea how to resolve this? I am baffled that starting a completely clean project right off the bat cannot even build. I tried adding the NuGet 'System.Runtime.Metadata' package - first the current 7.x, then explicitly the 6.0.0 version indicated in the error, but properties for this also don't include an option to 'Copy Local', and it makes no difference for getting this error.

I was hoping to at least attempt to do an initial implementation of a VSTO Add-In we have in Excel-DNA rather than jump into Add-In Express, but ... I need to be able to build at least the basic project off the bat :/

Thanks,

Mickey

 

[Michael Goldsworth]

I have no idea what happened, I guess nevermind? As soon as I added the registry key entry indicated by the error output, the project build with 0 issues.

Wtf? Just more fun stuff from Microsoft? Fantastic ...

Well, in case anyone else hits the same issue, try that, maybe it will go away for you too.

Thanks,

Mickey

[Michael Goldsworth]

Well, apparently it's not gone, just appears to be intermittent now. A rebuild shows the reference failure again. Just doing a build solution right after that shows 0 succeeded, 0 failed, but is producing the .xll file and debug objects.

It would still be great to get some insight from anyone else that may have hit anything like this. It's weird. Just, weird.

Thanks

[Alexander Rickman]

Hi Michael,

I’ve had this error occur in the following scenarios:

1. Projects stored on OneDrive: I resolved this by copying the entire project to the disk and building there.
2. Security software blocking a DLL: Sometimes third-party antivirus software blocks certain DLLs. The only way to fix that it to report it as a false positive to the offending third-party and hope they remove it from their blocked list.
3. If a required package reference is not set to Copy Local == True: This property can be found by clicking on a reference in the Solution Explorer (see images below) and changing it there.

​

[Michael Goldsworth]

Hi Alexander,

I will check these out, thank you very much for responding.

On #3 though, I don't seem to find that option anywhere. It seems Microsoft may have removed this for package references for newer versions of Visual Studio (I'm running 2022 17.1.6). I'm wondering if you're running Visual Studio 2019 and if I should consider switching to that to get this working.

However, if you are using 2022, then I'm really wondering what I'm missing. I see several other people across many different posts having the same or related issues and in which they also don't have that option to set Copy Local to True.

I will double check AV (I only use the default Microsoft Security, no installed AV) but suspect it's the 3rd option I need, and don't know how to resolve that since the option just isn't there.

Thanks,

Mickey

[Michael Goldsworth]

This is such a weird experience.

So, I loaded up Visual Studio 2022 on another box, and was able to create and build the project without any error about Sytem.Runtime.Metadata. That is good.

However, when I attempt to then debug, I don't get the expected security notice when Excel opens. Instead I get errors about not finding a series of xlsx files:

Has anyone seen this before either?

[Michael Goldsworth]

I was at least able to just open a blank workbook and import the xll directly, but I'm wondering if there are some other settings or details that I missed that are needed to enable this functionality as intended.

Thanks,

Mickey

[Govert van Drimmelen]

Hi Mickey,

You are indeed running into a weird problem with the build.

Can you confirm what ExcelDna.AddIn package version you are referencing?

I would suggest working with the latest pre-release version 1.7.0-rc3.

I notice you are using quite an old version of Visual Studio 2022 (current is 17.5.3). Does the other PC (where the build works) perhaps have a newer version of VS 2022?

 It might be that we are missing a dependency for the build tasks in the NuGet package, and the problem only surfaces under older VS versions. In particular we have a dependency on System.Reflection.Metadata but we don't ship it with the ExeclDna.AddIn NuGet package - I'm not sure whether we need to or can be sure that it is present on the lowest version of .NET Framework we expect to build on (we require NET Framework 4.6.2 to build the add-in). I also see spurious reports of this file unexpectedly not being found or failing to load in other projects, but I can't really see a pattern.

You second problem is less strange - you've run into a bug where the debug settings (which are updated during the Excel-DNA build step) don't get set correctly if you have spaces in the project name. The exact message boxes you show would appear if I ran Excel from a command line prompt as 

    C:\Program Files\Microsoft Office\root\Office16>EXCEL.EXE Excel Add-In Test-AddIn

I guess your project is called "Excel Add-In Test" and then the default output file is created by Excel-DNA as %ProjectName%-AddIn, thus "Excel Add-In Test-AddIn". When the debug command line is then set, things go wrong since there is no quoting. I've filed the issue Project names with space break debug settings · Issue #588 · Excel-DNA/ExcelDna (github.com) to fix this. The workaround is to add quotes to the debug settings and then add a project property to stop the build from overwriting your debug settings:

<RunExcelDnaSetDebuggerOptions>false</RunExcelDnaSetDebuggerOptions>

If you go back to the original PC and plan to update Visual Studio to the latest, I'd be curious whether that alone fixes the initial problem.

Please write back if you still run into problems getting started with Excel-DNA and your add-in.

Your initial project name (OPC Toolkit) is also interesting - I've done a bit of OPC work myself, but never a general Excel add-in for it.

The RTD / IObservable style streaming that Excel-DNA makes easy, would be a great fit for an OPC client too.

So I'm happy to help if you run into any further issues.

-Govert

[Michael Goldsworth]

Hu Govert, thank you for responding.

Yes, I'm following the directions from "https://excel-dna.net/" explicitly and specifying "*-*" for the version, which pulled ExcelDna.Addin 1.7.0-rc3. Makes sense to go with what is current for sure. Before running on the second machine, I did upgrade Visual Studio 2022 to the latest, 17.5.3, to see if that may be the reason for the initial reference error for "System.Runtime.Metadata". It was on that second machine with a freshly updated Visual Studio that I started a brand new example project, and was able to compile without the "System.Runtime.Metadata" error, so that was definitely a plus and seems a resolution for that. From that, I went ahead and updated Visual Studio 2022 to 17.5.3 there as well and created a new project, which was also able to build without the "System.Runtime.Metadata" error, which seems to confirm that.

And OHHHHHH, that is fantastic to know about the project name. Yes, I created a new project and validated that the file reference errors in Excel when starting Debug are completely gone. It that can be added to the starting instructions on the "https://excel-dna.net/" home page, that would be awesome! I spend at least a fair amount of time programming around Excel, using openpyxl and pandas in Python, Interop library for some C# projects, more recently python oletools for github hooks and xlam parsing/versioning for commit diffs, and unfortunately but hopefully not much longer, VBA code, but hadn't come across any cases where Excel is called like that and might include a reference on start to a file with spaces like this. Completely makes sense now that you call it out, and I imagine others could easily run into the same issue off the bat.

The next thing to solve is that recommendations for keeping ExcelDna portable suggest using the NetOffice package (one example: https://medium.com/dataseries/excel-addin-software-frameworks-extending-the-microsoft-office-platform-ea90e06b4555). I'm not certain if that is still true, but yes, because of the nature of ICS work, we end up working with clients that sometimes have much older machines and versions of Excel and want to keep things as portable as possible. The current issue is that there aren't any builds, even prerelease, that currently support .NET 6.0. They seem close and hopefully will soon (they've been working to support it for around a year it looks), so maybe I just need to exercise patience while I focus on ExcelDna, but wondering if others here have pulled and locally built from the NetOffice dev/net6 to test functionality/compatibility with ExcelDna.

That is interesting to hear about your curiosity of OPC work. The ICS space ... has been a change coming from MS and then Tableau (pre Salesforce), and the contractor model is so very different. We've focused heavily on automation and accelerated tooling across several SCADA platforms now that allow for a great deal more control than any SCADA platform supports. Excel is so pervasive in this ecosystem that it just becomes par for the course, though we leverage Google Sheets, DBs, and other sources where it makes sense and is possible. We're getting to this point where we have customers that could really use and greatly want tooling like this, since it can fit into how they're already leveraging Excel, and in many cases allow them to have greater visibility and consistency of their tagging across various parts of their SCADA deployments (when not DCS-based, which often handles that already). This becomes even more desired given that contractor-based model, where integrators are frequently more concerned about getting the work done quickly than adhering to policies that, well, in all honestly, often don't exist for the client, even if they want and often really need that level of consistency.

Yeah, I'm just starting to dig in, but we're serious about finding a solution to this. In combination with other tooling, it would be just fantastic to be able to give customers this kind of tooling, regardless of the SCADA platform.

Thank you incredibly much for your help and quick responses Govert, I greatly appreciate that. I will certainly reach out with further questions, and it would be nice to keep you updated with progress we make if you're interested as well.

Mickey

[Michael Goldsworth]

To clarify my typos, yeah, builds work on both machines now :)

[Govert van Drimmelen]

Hi Mickey,

 

Since .NET Framework 4.0, the COM interop assembly parts that are used by your code are embedded inside the assembly during compilation.

This means we don’t have the same problems with different versions of the COM interop assemblies as before, and the NetOffice style wrapper is no longer needed.

 

You can add the “ExcelDna.Interop” package to your project to get the interop assemblies matching Excel 2013, and as long as the COM object model features that you use are available on the running Excel version (older or newer) it will work fine.

 

One important rule to keep in mind when doing COM interop  from your Excel-DNA add-in is to only talk to the COM object model from the main thread. Work that runs on a Task thread, a Timer callback or similar external event (network data received) should not use the COM object model directly to update Excel. You can, however, schedule work to run on the main thread in a context where COM usage is safe by calling ExcelAsyncUtil.QueueAsMacro.

 

-Govert

 

 

Has anyone seen this before either?

On Wednesday, April 5, 2023 at 11:26:38 AM UTC-6 Michael Goldsworth wrote:

Hi Alexander,

 

I will check these out, thank you very much for responding.

 

On #3 though, I don't seem to find that option anywhere. It seems Microsoft may have removed this for package references for newer versions of Visual Studio (I'm running 2022 17.1.6). I'm wondering if you're running Visual Studio 2019 and if I should consider switching to that to get this working.

 

However, if you are using 2022, then I'm really wondering what I'm missing. I see several other people across many different posts having the same or related issues and in which they also don't have that option to set Copy Local to True.

 

I will double check AV (I only use the default Microsoft Security, no installed AV) but suspect it's the 3rd option I need, and don't know how to resolve that since the option just isn't there.

 

Thanks,

Mickey

 

On Wednesday, April 5, 2023 at 5:45:30 AM UTC-6 Alexander Rickman wrote:

Hi Michael,

I’ve had this error occur in the following scenarios:

1. Projects stored on OneDrive: I resolved this by copying the entire project to the disk and building there.
2. Security software blocking a DLL: Sometimes third-party antivirus software blocks certain DLLs. The only way to fix that it to report it as a false positive to the offending third-party and hope they remove it from their blocked list.
3. If a required package reference is not set to Copy Local == True: This property can be found by clicking on a reference in the Solution Explorer (see images below) and changing it there.

​

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/1f955765-eb67-4d75-983b-c193afb3cdcan%40googlegroups.com.

[Kenneth Gabriel Birkedahl Fabricius]

If this is still relevant, I too can confirm, that updating past beyond 17.5.3 solves the problem with missing "System.Runtime.Metadata".

My VS Build Tools on my buildserver was at v.17.1.7, whilest my own VS installation was 17.8.0 (preview 4). Updating the buildserver to 17.7.6 fixed the issue.

Best,

Kenneth

[femKing]

Unfortunately I am also in this situation - but not able to immediately perform  visual studio update due to admin restrictions.  I should add that I didn't experience this until I updated from Excel DNA 1.6 to 1.7.

[Govert van Drimmelen]

Can you paste the exact error from your build?

 

I think building an Excel-DNA add-in requires at least .NET 4.7.2 installed.

What version of Visual Studio and .NET are you using to build the project?

 

-Govert

 

 

From: exce...@googlegroups.com <exce...@googlegroups.com> On Behalf Of femKing

Sent: Friday, December 15, 2023 11:40 AM
To: Excel-DNA <exce...@googlegroups.com>

 

 

Has anyone seen this before either?

On Wednesday, April 5, 2023 at 11:26:38 AM UTC-6 Michael Goldsworth wrote:

Hi Alexander,

 

I will check these out, thank you very much for responding.

 

On #3 though, I don't seem to find that option anywhere. It seems Microsoft may have removed this for package references for newer versions of Visual Studio (I'm running 2022 17.1.6). I'm wondering if you're running Visual Studio 2019 and if I should consider switching to that to get this working.

 

However, if you are using 2022, then I'm really wondering what I'm missing. I see several other people across many different posts having the same or related issues and in which they also don't have that option to set Copy Local to True.

 

I will double check AV (I only use the default Microsoft Security, no installed AV) but suspect it's the 3rd option I need, and don't know how to resolve that since the option just isn't there.

 

Thanks,

Mickey

 

On Wednesday, April 5, 2023 at 5:45:30 AM UTC-6 Alexander Rickman wrote:

Hi Michael,

I’ve had this error occur in the following scenarios:

1. Projects stored on OneDrive: I resolved this by copying the entire project to the disk and building there.
2. Security software blocking a DLL: Sometimes third-party antivirus software blocks certain DLLs. The only way to fix that it to report it as a false positive to the offending third-party and hope they remove it from their blocked list.
3. If a required package reference is not set to Copy Local == True: This property can be found by clicking on a reference in the Solution Explorer (see images below) and changing it there.

​

--

You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/0eca8781-486f-4a3b-bbd8-a12ab74b5e51n%40googlegroups.com.