No issue building project with older version ( v3) where there was only set of dll and since project target settings are set for "Any CPU". It built fine for both x86 and x64 builds and ran fine on both Win32 and Win64 boxes.
Downloaded and wanted to try the latest Teechart 2012 version ( 4.1.2012.7136)
Now that Steema is providing both x64 and x86 dll's, I want to use optimized x64 dll's
Question 1: Is my understanding correct ? Why two version of TeeChart dll's in the newer version ?
Build Test 1: x64 project build with new x64 TeeChart dlls
Copied dll's from folder C:\Program Files (x86)\Steema Software\Steema TeeChart for .NET 2012\net35\x64\ to the project folder. This because I want to build with x64 dll's
Get 2 kind of build errors when building x64 build:
Error1 'Could not load file or assembly 'TeeChart, Version=4.1.2012.7136, Culture=neutral, PublicKeyToken=9c8126276c77bdb7' or one of its dependencies. An attempt was made to load a program with an incorrect format.'
Error2:
'Could not load file or assembly 'TeeChart, Version=3.5.3225.32185, Culture=neutral, PublicKeyToken=9c8126276c77bdb7' or one of its dependencies. Invalid pointer (Exception from HRESULT: 0x80004003 (E_POINTER))'
Question2:
Do i need to update all licenses.licx files in the project ? I know these are generated automatically when adding TChart ? How do I handle situation when I am just updating TeeChart libraries ?
Question 3:
Why two different kind of errors ? All licenses.licx currently have text containing Version=3.5.3225.32185. I tried manually updating all licenses.licx files to the newer version but was not helpful.
Build Test 2: x64 project build with new x86 TeeChart dlls
Copied dll's from folder C:\Program Files (x86)\Steema Software\Steema TeeChart for .NET 2012\net35\x86\ to the project folder.
Everything Built fine and ran fine
Question 4: How did this build fine without any updating of licenses.licx files in the project?
Question 1: Is my understanding correct ? Why two version of TeeChart
dll's in the newer version ?
That's to leave all the options to the user regarding possible environment combinations.
Build Test 1: x64 project build with new x64 TeeChart dlls Copied
dll's from folder C:\Program Files (x86)\Steema Software\Steema
TeeChart for .NET 2012\net35\x64\ to the project folder. This because
I want to build with x64 dll's
Get 2 kind of build errors when building x64 build: Error1 'Could not
load file or assembly 'TeeChart, Version=4.1.2012.7136,
Culture=neutral, PublicKeyToken=9c8126276c77bdb7' or one of its
dependencies. An attempt was made to load a program with an incorrect
format.'
Besides copying the assembly have you updated the TeeChart.dll reference in your project? You could try removing it and assigning it to the x64 assembly.
Error2: 'Could not load file or assembly 'TeeChart,
Version=3.5.3225.32185, Culture=neutral,
PublicKeyToken=9c8126276c77bdb7' or one of its dependencies. Invalid
pointer (Exception from HRESULT: 0x80004003 (E_POINTER))'
You should probably update licenses.licx to the new version or use a minimal version agnostic licenses.licx as explained in tutorial 17. Tutorials can be found at TeeChart's program group.
Question2: Do i need to update all licenses.licx files in the project
? I know these are generated automatically when adding TChart ? How do
I handle situation when I am just updating TeeChart libraries ?
I recommend you using a versionless licenses.licx as told in previous reply.
Question 3: Why two different kind of errors ? All licenses.licx
currently have text containing Version=3.5.3225.32185. I tried
manually updating all licenses.licx files to the newer version but was
not helpful.
Probably because there are 2 issues: 1, the project can not find the TeeChart reference to which it was set. 2, the version of the TeeChart assembly found doesn't coincide with licenses.licx settings.
Build Test 2: x64 project build with new x86 TeeChart dlls Copied
dll's from folder C:\Program Files (x86)\Steema Software\Steema
TeeChart for .NET 2012\net35\x86\ to the project folder.
Everything Built fine and ran fine
Question 4: How did this build fine without any updating of
licenses.licx files in the project?
Maybe because the project TeeChart.dll reference hadn't been updated and was still pointing to a x86 TeeChart version.
Besides copying the assembly have you updated the TeeChart.dll reference in your project? You could try removing it and assigning it to the x64 assembly.
I am copying over the existing dll's then why would I have issue with references in the projects. Anyway I tried removing reference and adding them back just for the heck of it but that didnot make the error go away. I ended up adding x86 dll's in the project references and ofcourse updating licenses.licx to point to newer version and it builds x64 build fine. However, in order to get full optimization for x64 box, I am copying x64 dll's into the application folder. It runs fine.
This solves two problems:
1: Visual Studio designer needs x86 dll's so referencing x64 dll's in project references is not an option if we want to make any changes to UI using designer.
2: Fixes the build error for license compiler as outlined earlier.
Now I am thinking the Error '*Could not load file or assembly 'TeeChart, Version=4.1.2012.7136, Culture=neutral, PublicKeyToken=9c8126276c77bdb7' or one of its dependencies. An attempt was made to load a program with an incorrect format*" was genuine as it's coming from license compiler and just like designer it needs x86 dll's in the project references.
What do u think?
Question 1: Is my understanding correct ? Why two version of TeeChart dll's in the newer version ?
That's to leave all the options to the user regarding possible environment combinations.
I understand the flexibility. What I was trying to get an answer for was intention of having separate dll's in newer version. It used to be just one set of dll's back in 2008. So why now x64 and x86 version. I didnot see any help or release notes explaining the difference. Is x64 dll's optimized during runtime on x64 ?
Related
I've been going circles on this one for over a day now. I have a WPF project that is making use of sqlite-net-pcl.
I'm ready to package this project up into an MSI for distribution (x64). The first hitch was that I need to directly add the nuget for the dependency (SQLitePCLRaw.bundle_green). I've come across this before when a nuget package contains content files that need to find their way into the final release. Smooth sailing.
At this point, the bin/x64/release is good and runs fine. However, when I build an installer and run the installed version I get the following exception:
System.BadImageFormatException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatException: Cannot load a reference assembly for execution.
Doing a file compare between my release folder and the application install folder I find the following:
Binary Difference: System.Buffers.dll
Binary Difference: System.Numerics.Vectors.dll
Binary Difference: System.Runtime.CompilerServices.Unsafe.dll
Installer Only: netstandard.dll
Installer Only: System.Diagnostics.Tracing.dll
Installer Only: System.IO.Compression.dll
Installer Only: System.IO.Compression.FileSystem.dll
Installer Only: System.Net.Http.dll
After inspecting further and digging in to the DLLs, I find if I overwrite System.Runtime.CompilerServices.Unsafe.dll with the binary from my release folder everything works.
Digging in even further and inspecting the installer version of CompilerServices.Unsafe I realize that the installer is grabbing the dotnet core version of the DLL.
I've isolated this down to a single console app with a fresh installer project and only adding the content and output to the installer.
Why is the installer insisting that the dependency is a dotnet core version?
I'd like to find a real solution, but in the meantime I found some confirmation and a dirty workaround in this thread: https://developercommunity.visualstudio.com/content/problem/810090/visual-studio-installer-projects-extensions-incorr.html
Workaround option 1: In addition to adding the “Primary Output” of the project containing the package reference also add “Locally-Copied Items” for that project. This will result in the lib version of the assembly overwriting the ref version, giving you the behavior you want. However, you’ll also get a warning about the duplicate file being added, since as I said the lib version will be overwriting the ref version. This also could bring in additional files like xml doc files that should have no impact at runtime but may increase the size of the installer. These can also be individually excluded from the setup project.
This is going to be one of those questions for which there are hundreds of answers, so please bare with me as I have tried most of them!
I have been breaking up a very large project into smaller components with the view to slowly migrate it all to .NET Core.
Some Projects in my solution are now .NETstandard class libraries, and there are also some .Net Framework (4.7.8) projects.
I was getting on quite well today when suddenly I started getting this:
Could not load file or assembly 'ServiceStack.Text, Version=5.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The version installed in my projects is (was - read on...) 5.8.0.0
Now, I am not new to this error, I've found it before and it usually relates to either a project reference file, web.config or packages.config referencing a .DLL with a different version than that of the file in the /bin directory.
So I have been through all (34) project folders and deleted servicestack.text.dll in every project.
I have uninstalled it via NuGet in every project and reinstalled it.
I have checked every project's packages.config file and where they are .NETStandard projects, the project files and made sure that there are not references to ServiceStack.Text v 5.0.0.0
I have rebuilt, cleaned and restarted the solution, visual studio and my computer many times!
Then I noticed something...
In my .Net Framework projects, under References, if I click on the ServiceStack.Text file and view the Reference Properties, it shows Version: 5.0.0.0, but the Path is directing it at 5.8.0.0.
In the .NETStandard projects, it shows the correct version.
So then I thought maybe 5.9 can't work in the Framework projects, so I uninstalled it from every project and installed v 5.0.0.0 in every project. This then wouldn't build because Visual Studio threw errors in the .NETStandard projects saying "downgrade detected, please restore the updated version"
SO then I installed 5.9 (which is now the latest version) into all the .NETStandard projects, leaving 5.0.0.0 in the .NET Framework ones.
Now it will build, but the FileNotFound exception throws again when I try to run it.
So I have tried;
Everything using ServiceStack.Text 5.9
Everything using ServiceStack.Text 5.0
.NET Framework projects using 5.0 and .NETStandard (2.0) projects using 5.9
Uninstalling and reinstalling multiple times
Deleting all obj directories, cleaning and rebuilding
Checking all project and packages files
Wasted most of the day on this, so turned to SO... I do hope someone can help!
Right.... Answering my own Question again...
After a lot of messing about I found out what was happening, and it was nothing to do with Visual Studio builds, or .package file conflicts
The reason the error suddenly appeared was a call to Dump() in something I was testing, which had another call to Dump() in a preceding function referencing a different .NET Framework. Whilst according to Microsoft this (mixing Frameworks) works, ServiceStack has different versions and it caused a version conflict.
In case anyone else runs into this, here's what I have found…
Pseudo code example… a function in a .NET Standard Project (2.0)
Function Blah() as Something
… do something
Log(TestResult.Dump())
Return Something
End Function
And then a .NET Framework (4.7.8) Project which consumes this and again tries the Dump the result:
Sub DoSomething()
Dim Something = Blah()
Write(Something.Dump())
End Sub
The two frameworks require different versions of ServiceStack.Text and therefore throw a confusing, though I guess correct, FileNotFoundException in the running project.
I’m sure to run into this one again….!
In a Xamarin.Forms project I am getting an error on Windows 8.1 and UWP:
Could not load file or assembly 'FSharp.Core, Version=3.259.3.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
The actual version of F# used throughout the solution is 3.7.4.0:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile7</TargetFrameworkProfile>
<TargetProfile>netcore</TargetProfile>
<TargetFSharpCoreVersion>3.7.4.0</TargetFSharpCoreVersion>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
There is an F# PCL project and C# platform-specific projects. The error occurs only when using F# libraries from Nuget in the PCL. These packages tend to use:
<TargetFSharpCoreVersion>3.259.3.1</TargetFSharpCoreVersion>
I have tried the following, but they do not change the error:
Putting an app.config file with a binding redirect to 3.7.4.0 in the F# project and/or the build directory
Installing the FSharp.Core Nuget package into all projects
Very grateful for any help.
Edit: in the original question there was an incompatibility between the profile (111) and the intended TargetFSharpCoreVersion (3.7.4.0) which was causing additional issues.
I'm a bit confused as to what's happening here.
My understanding is that when an assembly is required at runtime, the runtime will first try to load the assembly from the executing directory (or the directory where the dependant executable is located). After which it will attempt to find the assembly within the GAC.
First of all, I am on Windows.
Now, when I'm compiling my solution is VS, everything works fine (as expected), but when I compile the same solution in MonoDevelop, the compilation stops due to errors pertaining to a missing log4net reference (the exact assembly for which I manually installed into the GAC to avoid this situation).
So, my question is this: Does MonoDevelop look at the GAC at compilation time to determine if an assembly is available, or is there another location in which I need to provide the required assembly?
Thank you for your help!
From MonoDevelop site:
I added an assembly to the GAC, why doesn't it appear in the assemblies list when I try to add a reference in a MonoDevelop project?
Bacause MonoDevelop does not look for assemblies in the GAC. On Mac
and Linux, MonoDevelop uses pkg-config to locate installed packages
and get the list of assemblies that each package provides. A package
specifies this list of assemblies in a .pc file which has to be
installed in the standard pkg-config directory.
If you are developing a library, MonoDevelop can automatically
generate a .pc file for your project (in the project options dialog,
select "Linux Deployment Settings", and check the "Generate .pc file"
option).
When targetting .NET on Windows, MonoDevelop uses the same
AssemblyFolders mechamisn that VS uses.
I've recently taken over a project, and the original developer has gone. I'm now trying to install the app on a new server, and I've got a problem with dependent assembly versions.
The project is a reporting tool, with (unfortunately) a reference to Crystal. On my machine I have version 11.5.9500.313 of CrystalDecisions.CrystalReports.Engine.dll.
The NAnt script that does the build defines the references, including the Crystal dll, but does not define the version number.
When I build the app, using the NAnt script, and analyse the assembly with Reflector, the reference is for version 11.5.3300.0.
Can anyone explain where the version number of this reference comes from?
Assembly version (from AssemblyVersionAttribute) is not necessarily the same as the file version (from AssemblyFileVersionAttribute). Unless you use a tool which returns the assembly version consistently (e.g. Reflector) comparing versions is going to be completely unreliable.
It comes from the references in the vs. project file. Open the project file in a text editor and check it out. Anyway, to fix re-add the references in the visual studio.