I was wondering if you could point me in the right direction here. I'm having trouble with the Glyph when creating a Extension / ChildWindow. The helper method CreateExtensionMenuItem references System.Drawing.Image. I added the package System.Drawing.Common and everything compiles correctly but I receive the following error:
System.Windows.Markup.XamlParseException: The invocation of the constructor on type 'WealthLab7.MainWindow' that matches the specified binding constraints threw an exception.
---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Drawing.Common, Version=5.0.0.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'System.Drawing.Common, Version=5.0.0.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
at WealthLab.Custom.Extensions.PortfolioBuilder.Initialize()
at WealthLab.WPF.ExtensionsFactory.Initialize(IWLClientHost host)
at RuleInterpreter.InterruptTask(Object , IWLClientHost , RuleInterpreter )
at WealthLab7.MainWindow..ctor()
Here are some notes to the documentation so far:
- Project should be a .NET Core WPF Library (not Core Library)
- When creating a ChildWindow
a) add xml reference to the xml xmlns:wwpf="clr-namespace:WealthLab.WPF;assembly=WealthLab.WPF"
b) change the xml from Window to wwpf:ChildWindow
c) change .cs to inherit from WPF.ChildWindow
System.Windows.Markup.XamlParseException: The invocation of the constructor on type 'WealthLab7.MainWindow' that matches the specified binding constraints threw an exception.
---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Drawing.Common, Version=5.0.0.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'System.Drawing.Common, Version=5.0.0.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
at WealthLab.Custom.Extensions.PortfolioBuilder.Initialize()
at WealthLab.WPF.ExtensionsFactory.Initialize(IWLClientHost host)
at RuleInterpreter.InterruptTask(Object , IWLClientHost , RuleInterpreter )
at WealthLab7.MainWindow..ctor()
Here are some notes to the documentation so far:
- Project should be a .NET Core WPF Library (not Core Library)
- When creating a ChildWindow
a) add xml reference to the xml xmlns:wwpf="clr-namespace:WealthLab.WPF;assembly=WealthLab.WPF"
b) change the xml from Window to wwpf:ChildWindow
c) change .cs to inherit from WPF.ChildWindow
Rename
I’m not at the computer at the moment but you should be sure to add the same System.Drawing.Common version as the one included in the WL7 install folder.
Thank you Dion. That did it. It was version 4.7.2 if anyone runs into the same issue.
Okay, I downloaded the system.drawing.common.4.7.2.nuget file. However, when I double-click it, Visual Studio opens it for binary file inspection instead of unpacking it. How do I get Visual Studio to actually unpack it?
Nuget packages are just zip files.
Is there a way to get Visual Studio to unzip the nuget package and install it as part of the VS project like it normally would coming directly from the nuget archive?
I downloaded this package because Visual Studio couldn't find the desired version in the usual nuget archive, which only lists the 5.0.2 version.
I downloaded this package because Visual Studio couldn't find the desired version in the usual nuget archive, which only lists the 5.0.2 version.
You should choose the right version to install straight in Visual Studio.
QUOTE:And I totally agree with you. So tell me how to do that? My stupid version of Visual Studio only displays version 5.0.2 and I've burn lots of time trying to override that before even posting this question to the forum in the first place. I'm now at a total loss. How do get VS to show version 4.7.2? Am I missing a VS configuration?
You should choose the right version to install straight in Visual Studio.
And an even better way would be to include the correct version of System.Drawing.Common in the WL7 distribution in the first place so all this hassle would be unnecessary. What we are doing now is a big waste of time for both of us.
This is the fourth posting, and we are just going in circles here with no progress.
It's already installed in your solution so try uninstalling it first.
QUOTE:That did the trick--thanks. You have to uninstall the latest one before you can install an older one. Visual Studio won't let you have two different versions installed into the same project.
try uninstalling it first.
Ya, I didn't appreciate that. But it makes sense if the versions aren't compatible.
I still think simply distributing this assembly with WL7 would be easiest. But perhaps that's too easy.
WL7 does distribute the assembly. If it didn't, WL7 would crash upon startup.
It's still necessary to reference the same version in any custom extensions you might develop.
It's still necessary to reference the same version in any custom extensions you might develop.
QUOTE:
I still think simply distributing this assembly with WL7 would be easiest. But perhaps that's too easy.
As said in Dion's Post #1.
QUOTE:Well, System.Drawing.Common wasn't in my WL7 directory. But perhaps there's a problem with my WL7 install. Whenever I try to install a new Build of WL7, the installer gripes about updating some Core 3.1 package and that my current install is more current than the one being installed, so I skip that installer step.
WL7 does distribute the assembly. If it didn't, WL7 would crash upon startup.
Hmm. Maybe I should just delete the entire WL7 install directory and do a clean install? At any rate, it's all running correctly, so I'm good.
Actually I was wrong, it's not included in the install, my mistake! It's included in the solution via Nuget, so I'm not sure why Visual Studio doesn't copy it to the bin folder.
It seems to be a known issue,
https://github.com/dotnet/sdk/issues/11489
It looks like what is happening is that it's not putting the dll into the bin folder because it's part of the shared framework. It's still all a bit weird and I don't fully understand what's going on with this dll.
It seems to be a known issue,
https://github.com/dotnet/sdk/issues/11489
It looks like what is happening is that it's not putting the dll into the bin folder because it's part of the shared framework. It's still all a bit weird and I don't fully understand what's going on with this dll.
QUOTE:That's because we do not want VS to copy stuff into the WL7 install (target) folder. See the two "false" statements in Local.Components.csproj file below. Having VS copy stuff automatically creates unwanted problems.
It's included in the solution via Nuget, so I'm not sure why Visual Studio doesn't copy it to the bin folder.
CODE:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netcoreapp3.1</TargetFramework> <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath> <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath> <Authors>Mark M Mehl</Authors> <Company>Automated Measurement Engineering</Company> <Copyright>Copyright © 2016-2021</Copyright> <Description>Weath-Lab 7 supplemental common-code component library</Description> </PropertyGroup>
From Reply# 2:
I noticed there's a version 4.7.3 of System.Drawing.Common. Should I be upgrading to that now?
I also noticed there are a number of other versions going up to 7.0.0. Would they be more appropriate? Note, I probably won't be needing WL7 or Core 3.1 again.
QUOTE:
It was version 4.7.2 if anyone runs into the same issue.
I noticed there's a version 4.7.3 of System.Drawing.Common. Should I be upgrading to that now?
I also noticed there are a number of other versions going up to 7.0.0. Would they be more appropriate? Note, I probably won't be needing WL7 or Core 3.1 again.
Why the need for this assembly?
So you're saying .NET 6.0 and WL8 don't need it?
Yes
Your Response
Post
Edit Post
Login is required