I have c# application and when I made a change, I am getting the error message:
An unhandled exception of type 'System.TypeLoadException' occurred in
WindowsFormsApplication1.exe
Additional information: Could not load type
'TradeIdeas.TIProData.OddsMakerColumnConfiguration' from assembly
'TIProData, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’.
This message says the version number of dll (TIProData) is 1.0.0.0. I think there is a later version available. How can I tell the version number of a dll on my machine?
You can use Reflector, ILDASM or ILSpy to get the assembly version.
You usually can find ILDASM in C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\ildasm.exe (where v8.1A is the version of the Windows SDK installed).
ILDASM:
Reflector:
There is a couple of ways to do it:
If you reference the dll in Visual Studio right click it (in ProjectName/References folder) and select "Properties" you have "Version" and "Runtime Version" there.
In File Explorer when you right click the dll file and select properties there is a "File Version" and "Product Version" there.
Alternatively, investigate it in code:
Assembly assembly = Assembly.LoadFrom("TestAssembly.dll");
Version ver = assembly.GetName().Version;
If you know Class, that belongs to assembly, you can use GetTypeInfo
var runtimeVersion = typeof(MyClass)
.GetTypeInfo()
.Assembly
.GetCustomAttribute<AssemblyFileVersionAttribute>();
String ver=RuntimeVersion.Version;
The example is for .Net Core
from https://developers.de/blogs/damir_dobric/archive/2017/06/27/how-to-deal-with-assembly-version-in-net-core.aspx
You can use AssemblyName.GetAssemblyName(string path) from a little util app.
Further details here on MSDN.
From Powershell (PSCore):
$assembly = [System.Reflection.Assembly]::LoadFrom("$pwd\System.Memory.dll")
Besides $assembly.FullName you can pick up any other prop from the object.
Related
We have a fairly large solution containing a mix of C++/CLI and C# projects using MFC and Winforms controls to build the UI. Several MFC dialogs in the app make use of a CWinFormsControl from afxwinforms.h to embed WinForms controls inside them, currently everything targets .NET48 and works fine. We are trying to update everything to .NET6.0 and everything seems OK except the one project that includes afxwinforms.h.
The project settings are:
Common Language Runtime Support: .NET Core Runtime Support(/clr:netcore)
.NET Core Target Framework: net6.0-windows (I have tried just net6.0, net5.0...)
Platform Toolset: Visual Studio 2022 (v143)
We include <afxwinforms.h> amongst several other afx includes in a precompiled header and the compiler gives this error building our stdafx.h:
C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.30.30705\atlmfc\include\afxwinforms.h(30,8):
fatal error C1107: could not find assembly 'System.Windows.Forms.dll':
please specify the assembly search path using /AI or by setting the
LIBPATH environment variable
From some searching on the internet I found and attempted to pass the following directories using the Additional #using Directories property of the project:
C:\Program Files (x86)\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.0\
C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.0\ref\net6.0\
C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.0\
Any of those paths seems to sort out the above compiler error, and intellisense seems to recognise everything in afxwinforms.h too. However, the compiler starts giving warnings such as:
C:\Program Files (x86)\Windows
Kits\10\Include\10.0.22000.0\um\objidl.h(9724): message : see
declaration of 'IPersist' C:\Program Files (x86)\Windows
Kits\10\Include\10.0.22000.0\um\objidl.h(11125): message : see
declaration of 'IPersistStorage' C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.30.30705\atlmfc\include\afxwinforms.inl(32):
message : This diagnostic occurred while importing type
'System::Windows::Forms::Control ' from assembly
'System.Windows.Forms, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'. C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.30.30705\atlmfc\include\afxwinforms.inl(32,3):
warning C4691: 'IQuickActivate': type referenced was expected in
unreferenced module 'System.Windows.Forms.Primitives', type defined in
current translation unit used instead C:\Program Files\Microsoft
Visual
Studio\2022\Professional\VC\Tools\MSVC\14.30.30705\atlmfc\include\afxwinforms.inl(32,3):
message : This diagnostic occurred while importing type
'System::Windows::Forms::Control ' from assembly
'System.Windows.Forms, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'. C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.30.30705\atlmfc\include\afxwinforms.inl(32,3):
warning C4691: 'IOleInPlaceUIWindow': type referenced was expected in
unreferenced module 'System.Windows.Forms.Primitives', type defined in
current translation unit used instead C:\Program Files\Microsoft
Visual
Studio\2022\Professional\VC\Tools\MSVC\14.30.30705\atlmfc\include\afxwinforms.inl(32,3):
message : This diagnostic occurred while importing type
'System::Windows::Forms::Control ' from assembly
'System.Windows.Forms, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'.
before giving this error:
C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.30.30705\atlmfc\include\afxwinforms.inl(32,3):
fatal error C1001: Internal compiler error. (compiler file
'd:\a01_work\20\s\src\vctools\Compiler\CxxFE\sl\p1\c\cpimport.cpp',
line 12502) To work around this problem, try simplifying or changing
the program near the locations listed above.
So, my main questions are:
Is it possible to do this, can I embed a WinForms control in an MFC dialog using a CWinFormsControl in .NET6.0?
If it is possible, where am I going wrong causing the problems above?
If it isn't possible, is there an alternative way to do something like this: (trimmed down sample)
//C#
public class MyUserControl : System.Windows.Forms.UserControl
{
}
//C++
#include <afxwinforms.h>
class MyWnd : public CWnd
{
public:
CWinFormsControl<MyUserControl> mMyControl;
int OnCreate(LPCREATESTRUCT lpCreateStruct)
{
auto rc = __super::OnCreate(lpCreateStruct);
if (rc >= 0)
{
CRect rcChild(0, 0, lpCreateStruct->cx, lpCreateStruct->cy);
m_optionsControl.CreateManagedControl(WS_CHILD | WS_VISIBLE, rcChild, this, 1);
}
return rc;
}
};
I can reproduce this in a quick, small sample.
In Visual Studio 2022 create a new project, CLR Empty Project (.NET)
Add a header and source file, include the header from the source. #include <afxwinforms.h> to the header file.
Project->Properties->Configuration Properties->Advanced:
Use of MFC: Use MFC in a shared DLL
Common Language Runtime Support: (should already be) .NET Core Runtime Support (/clr:netcore)
.NET Core Target Framework: (should already be) net6.0
Build the project, you should get an error about not being able to find the System.Windows.Forms.dll.
Project->properties->Configuration Properties -> C/C++ -> General: Additional #using Directories:
C:\Program Files (x86)\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.0\ OR
C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.0\ref\net6.0\ OR
C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.0<br />
Build again, you should get the internal compiler error.
i was trying to solve the same issue. From the code inside mfc its clear they only support .net framework for now.
What worked for me was to make a copy of the afxwinforms.h and .inl plus some files from "C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.32.31114\atlmfc\src\mfcm" into my project directly so it stops linking into the microsoft mfcmXXX.lib and just adjusted the files slightly to get it to compile.
Here is how I fix it:
Use Visual Studio 2022, in project.vcxproj, add this reference:
<ItemGroup><FrameworkReference Include="Microsoft.WindowsDesktop.App.WindowsForms" /></ItemGroup>
Then, you will see "System.Windows.Forms.dll" in "External Dependencies" of Solution Explorer. Look at the properties for this dll, which is under: C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.7\ref\net6.0\System.Windows.dll
open project's property, Configuration Properties -> C/C++ -> General -> Additional #Using Directories, add the folder's full path there.enter image description here
(I just use net6.0, not net6.0-window)
I had a problem running my C# application throwing the following error when trying to use a certain reference as follows:
Could not load file or assembly 'My3rdPartyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)"
Then I followed this answer for signing the assembly in question.
I can confirm via Visual Studio and Sn as well that my DLL is now definitely signed and has a strong name.
However I am seeing 2 things:
On my signed version of the application I still get the same error as above as if the assembly does not have a strong name.
On my unsigned version which was working fine until now with the unsigned DLL, it now throws the same error with the signed version of the DLL.
I am out of clue on what could be the reason.
Thx for the help.
It turns out that I was able to solve it. I was updating the third-party library (the assembly that I want to sign) so that it can work well with my .exe BUT it gets replaced by an unsigned version that came from the NuGet package.
You'll have to update the .dll in the following location:
I will have instruction for an example package named WPFCustomMessageBox.dll. Follow the ff. steps to update the package and have it reflect on the debug folder:
Open cmd in the path provided above.
Type the ff. You should organize the path in your system as your folder structure and where your files are located may not be the same as mine:
a. This one gets the necessary files from the .dll
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\Ildasm.exe" /all /out=WPFCustomMessageBox.il WPFCustomMessageBox.dll
b. I'm not sure what this one does but it preps the file for the next command.
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Ilasm.exe" "WPFCustomMessageBox.il" /dll /resource="WPFCustomMessageBox.res" /key="publickey.snk"
c. This one creates the signed .dll
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\sn.exe" -R "WPFCustomMessageBox.dll" "pair.pfx"
Type the password for your .pfx file and it should make the signed .dll.
I've tested this method with the aid from Adding a Strong Name to a Third-Party Assembly. The next time you compile, the former unsigned .dll that gets compiled/copied over to the Debug folder should be signed. Hope this helps :)
Hi and thanks in advance.
I'm using TFS build 2013 (team services, not on premise) to build my solution. After creating a new C++ project in the solution I'm unable to build successfully.
The error I'm getting on the build machine is:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.targets
(219): An error has occurred during compilation. error CS1705: Assembly 'Microsoft.Build.Utilities.Core,
Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' uses 'Microsoft.Build.Framework,
Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher
version than referenced assembly 'Microsoft.Build.Framework, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.targets
(219): The "SetEnvironmentVariable" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name
of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask
interface. 3.) The task is correctly declared with <UsingTask> in the project file, or
in the *.tasks files located in the "C:\Program Files (x86)\MSBuild\14.0\bin\amd64" directory.
I've red about error CS1705 on the internet but I still don't understand why I get this error - the project is an empty project which has no references what so ever and no other project reference it either.
I'm targeting .NET framework 4.6.1 on all my C# projects and in my build definition I'm adding these msbuild arguments: /tv:14.0 /p:VisualStudioVersion=14.0 hence it uses the 2015's version of the c# compiler.
The target platform for this C++ project is VS 2015 (v140) as follows:
C++ project configuration
Needless to say that when I'm removing this project from the list of project to build (configuration manager) - the solution builds successfully.
Any help/clue would be greatly appreciated!
The problem was something other than what I thought it was. Seems it's got something to do with CodeAnalysis and some environment variable related to it.
In my build definition I'm disabling CodeAnalysis and even inside the C++ project properties It's explicitly disabled. After I commented out some attributes on the "SetCABuildNativeEnvironmentVariables" target inside this file on the build machine:
"C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\CodeAnalysis\Microsoft.CodeAnalysis.targets"
The problem disappered.
This is a nasty workaround however since I'm not fully aware of what's really happening.
Thanks a lot anyways!
Seems there are something still point to "Microsoft.Build.Framework, Version=12.0.0.0"
The /tv:14.0 command argument doesn't work as expected. See:
BuildActivity ignores ToolsVersion
As a workaround, you need to customize the build process template:
Open the template in Visual Studio and find the Run MSBuild for
Project MSBuild activity.
Set ToolVersion to "14.0".
Set ToolPath to target to MSBuild14 (by default: "C:\Program Files
(x86)\MSBuild\14.0\Bin").
Check in this build process template and re-queue the build.
You can also refer the answer from Marson in TFS 2013 building .NET 4.6 / C# 6.0
I have a C# console application (.Net version 3.5) with following code
static void Main(string[] args)
{
IWshRuntimeLibrary.WshNetwork aNetworkInstance = new IWshRuntimeLibrary.WshNetwork();
}
When I run the program it is throwing following error.
An unhandled exception of type 'System.BadImageFormatException'
occurred in Microsoft.VisualStudio.HostingProcess.Utilities.dll
Additional information: Could not load file or assembly
'Interop.IWshRuntimeLibrary, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its dependencies. This assembly is
built by a runtime newer than the currently loaded runtime and cannot
be loaded.
I found that the generated interop file Interop.IWshRuntimeLibrary.dll is refering to 4.0.0.0 version of mscorelib.
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
.ver 4:0:0:0
}
If I change the .net version of the project to 4, then it is working fine. Any idea why the Interop.IWshRuntimeLibrary.dll is always refering to version 4 of mscorlib even when I select .net 3.5 in the project?
PS: The same program is working in other systems. The issue is only in one system.
EDIT: Following are the steps I have done.
Create a C# Console application (.Net version 3.5).
Add referece to Windows Scribt Host Object model
Add following line in the Main()
static void Main(string[] args)
{
IWshRuntimeLibrary.WshNetwork aNetworkInstance = new IWshRuntimeLibrary.WshNetwork();
}
When I run the application, it is throwing following exception.
An unhandled exception of type 'System.BadImageFormatException'
occurred in mscorlib.dll
Additional information: Could not load file or assembly
'Interop.IWshRuntimeLibrary, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its dependencies. This assembly is
built by a runtime newer than the currently loaded runtime and cannot
be loaded.
I am able to build and run the project in other machines.
If I copy the Interop.IWshRuntimeLibrary.dll generated in another machine, then also the program is running in my machine.
But I am not able to run the program with the Interop.IWshRuntimeLibrary.dll generated in my machine.
I know it is a strange problem. May be I have to reformat my hard disk as you suggested by Hans Passant :(
EDIT: Output of the detailed build
1> C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\TlbImp.exe C:\Windows\SysWOW64\wshom.ocx /namespace:IWshRuntimeLibrary /machine:X86 /out:obj\x86\Release\Interop.IWshRuntimeLibrary.dll /sysarray /transform:DispRet /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll" /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll" /reference:C:\WINDOWS\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll
1> Microsoft (R) .NET Framework Type Library to Assembly Converter 4.0.30319.33440
1> Copyright (C) Microsoft Corporation. All rights reserved.
1>
1> TlbImp : Type library imported to C:\Users\IC007121\Documents\Visual Studio 2013\Projects\wsherrortest\wsherrortest\obj\x86\Release\Interop.IWshRuntimeLibrary.dll
1> Resolved COM reference for item "IWshRuntimeLibrary": "obj\x86\Release\Interop.IWshRuntimeLibrary.dll".
Visual Studio uses a SDK tool named TlbImp.exe to build COM references import files. The MsBuild task that does that is named ResolveComReference. This task uses an algorithm that tries to find the proper TlbImp version on the machine that builds the project.
In your case as we see it from msbuild diagnostics, it uses the TlbImp from "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools". Unfortunately, this TlbImp builds CLR 4 assemblies. So you need to use another TlbImp. On my machine, it uses it from "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin" which builds CLR 2 assembly. You probably don't have that TlbImp installed on your build machine so the algorithm redirects silently to the newer one (sounds like a bug, I think it should report the problem, but I'm unsure).
To fix this, you can install an older version of Visual Studio or Windows SDK and it should work magically, or you can configure your project to use a proper TlbImp V3.5 if you have it on your machine somewhere (if you don't have it, then you must install something).
Here is how to modify the MsBuild project from Visual Studio:
right click on the project node, Unload Project
right click on the project node and Edit Project
add the following line to your msbuild project file
right click on the project node and Reload project
rebuild
...
<PropertyGroup>
... other properties ...
... <ResolveComReferenceToolPath should point to a directory that contains TLBIMP V3.5
<ResolveComReferenceToolPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin</ResolveComReferenceToolPath>
</PropertyGroup>
...
I am now dealing with a existing solution in VS2012.
Now I can execute it in debug mode but cannot trigger some of the function with the error
"Exceptions: System.Exception: Could not load file or assembly
'Interop.Score, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=5ce8a8a190705d24' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)"
After finding some of the suggestion, some of that suggest me to compile the solution in 32-bit (x86).
However, when I tried to rebuild with the target platform x86, another type of error occur and I even cannot run in debug mode, the error:
Referenced assembly 'GenCode128.dll' is not a valid assembly C#
P.S. GenCode128.dll is one of the error .dll, there is at least 2 of this kind of error.
I cannot search any successful way to solve this problem, appreciate for any help.
You can use a decompiler such as DotPeek (https://www.jetbrains.com/decompiler) to look inside your DLL and see if it is a valid .NET DLL -- and which version of .NET it is. It could be an x64-compiled assembly; in that case you cannot use it on a 32-bit system or from a 32-bit-compiled .NET assembly.
You can try installing it from NuGet.
I've created a NuGet package for GenCode128.dll here: https://www.nuget.org/packages/GenCode128/
Also the source can be found in GitHub: https://github.com/SourceCodeBackup/GenCode128