Requirement of 64-bit version Microsoft DLLs

Question

User-536888146 posted

Hi,

Introduction

We are working on a .net project, in which we are using some of Microsoft's DLLs. The list of DLLs are:
System.*
Microsoft.*
(A complete list of DLLs is attached to this post.)

Requirement

We require 64-bit version DLLs only and at the moment, we only have 32-bit version DLLs in our hand.

Things that we have tried

We verified the DLLs' version using a tool named SigCheck.

We tried to find/convert the DLL version on our own using the following methods: <div>1) We searched on the internet and NuGet Package Manager. but, we were not able to find 64-bit DLLs.
2) We tried recompiling our project to 64 bit by changing below setting under project properties:
- Build -> Platform Target -> x64
After compilation, our project DLL got converted to 64-bit. However, the remaining project DLLs' version didn't change.

Question

We would be grateful if someone could share documentation links/steps to convert 32-bit version DLLs to a 64-bit version? or
Could someone please send us a recompiled 64-bit version of the given DLLs?

Please note that we are using .net framework 4.6 so please provide 64 bit dlls which are compatible with .net framework 4.6

Complete list of DLLs

Vendor	DLLs	Version
Microsoft	Microsoft.Practices.EnterpriseLibrary.Common.dll	5.0.414.0
Microsoft	Microsoft.Practices.EnterpriseLibrary.Data.dll	5.0.414.0
Microsoft	Microsoft.AI.Agent.Intercept.dll	1.2.0.1011
Microsoft	Microsoft.AI.DependencyCollector.dll	1.2.3.246
Microsoft	Microsoft.AI.PerfCounterCollector.dll	1.2.3.246
Microsoft	Microsoft.AI.ServerTelemetryChannel.dll	1.2.3.246
Microsoft	Microsoft.AI.Web.dll	1.2.3.246
Microsoft	Microsoft.ApplicationInsights.dll	1.2.3.490
Microsoft	Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll	1.0.20615.0
Microsoft	Microsoft.Practices.ServiceLocation.dll	1.0.0.0
Microsoft	Microsoft.Practices.Unity.Configuration.dll	2.0.414.0
Microsoft	Microsoft.Practices.Unity.dll	2.0.414.0
Microsoft	Microsoft.Practices.Unity.Interception.Configuration.dll	3.0.1304.0
Microsoft	Microsoft.Practices.Unity.Interception.dll	2.0.414.0
Microsoft	Microsoft.Data.Edm.dll	5.2.0.51212
Microsoft	Microsoft.Data.OData.dll	5.2.0.51212
Microsoft	Microsoft.Web.Infrastructure.dll	1.0.20105.407
Microsoft	Microsoft.Web.Mvc.FixedDisplayModes.dll	1.0.0.0
Microsoft	Microsoft.Web.RedisSessionStateProvider.dll	2.2.0.311
Microsoft	Newtonsoft.Json.dll	4.5.11.15520
Microsoft	Microsoft.AI.WindowsServer.dll	1.2.3.246
Microsoft	System.Net.Http.WebRequest.dll	1.0.0.0
Microsoft	System.Runtime.CompilerServices.Unsafe.dll
Microsoft	System.Runtime.dll	4.6.1055.0
Microsoft	System.Threading.Tasks.dll	2.6.10.0
Microsoft	System.Threading.Tasks.Extensions.dll	4.6.26515.06
Microsoft	System.Web.Http.dll	4.0.20710.0
Microsoft	System.Memory.dll
Microsoft	System.Net.Http.Formatting.dll
Microsoft	System.Web.Cors.dll
Microsoft	System.Web.Http.Cors.dll
Microsoft	System.Web.Http.WebHost.dll
Microsoft	System.Spatial.dll	5.2.0.51212
Microsoft	System.Web.DynamicData.dll	4.6.81.0
Microsoft	System.Web.Helpers.dll	2.0.20710.0
Microsoft	System.Web.Http.OData.dll	4.0.20208.0
Microsoft	System.Web.Http.Tracing.dll	4.0.20710.0
Microsoft	System.Web.Mvc.dll	4.0.20710.0
Microsoft	System.Web.Optimization.dll	1.1.40211.0
Microsoft	System.Web.Providers.dll	1.2.0.0
Microsoft	System.Web.Razor.dll	2.0.20715.0
Microsoft	System.Web.WebPages.Deployment.dll	2.0.20710.0
Microsoft	System.Web.WebPages.dll	2.0.20710.0
Microsoft	System.Web.WebPages.Razor.dll	2.0.20710.0
Microsoft	System.Net.Http.dll
Microsoft	System.Buffers.dll	4.6.25519.03
Microsoft	System.ValueTuple.dll	4.6.26515.06

Answer 1

User-1330468790 posted

Hi pranav.jain,

 

After compilation, our project DLL got converted to 64-bit. However, the remaining project DLLs' version didn't change.

I think it is not related to the 64-bit assemblies. If you want to change the project DLLs' version, you might need to check if you have configured for increase the assembly version.

• Go to Solution Explorer
• Right Click on your project
• select properties
• In the window that appears click Assembly Information
• In the pop-up box you can edit assembly related details

• Click 'ok' and your AssemblyInfo.cs file can be seen updated automatically

If you change the 3rd box for version information to “*”, now each time when you build the solution or project, it will generate a version number like 1.0.X.Y, where X is the number of days from year 2000/1/1 and Y is the number of seconds from midnight divided by 2.

  

Requirement

We require 64-bit version DLLs only and at the moment, we only have 32-bit version DLLs in our hand.

For this requirement, I am afraid that it is a bit unreasonable. .NET Framework's compiler supports creating 64-Bit applications. 

By default, when you use the .NET Framework to build an application on either a 32-bit or a 64-bit computer, the application will run on a 64-bit computer as a native application (that is, not under WOW64). 

Many assemblies run identically on both the 32-bit CLR and the 64-bit CLR. However, some programs may behave differently, depending on the CLR, if they contain one or more of the following:

• Structures that contain members that change size depending on the platform (for example, any pointer type).

• Pointer arithmetic that includes constant sizes.

• Incorrect platform invoke or COM declarations that use Int32 for handles instead of IntPtr.

• Code that casts IntPtr to Int32.

For more information about how to port a 32-bit application to run on the 64-bit CLR, see Migrating 32-bit Managed Code to 64-bit.

 

By extracting from the official document, you could get below information:  Designing 64-bit-Compatible Interfaces

Porting from 32-bit Windows to 64-bit Windows should not, by itself, create any problems for distributed applications, whether they use Remote Procedure Calls (RPC) directly or through DCOM. The RPC programming model specifies well-defined data sizes and integer types that are the same size on each end of the connection. Also, in the LLP64 abstract data model developed for 64-bit Windows, only the pointers expand to 64 bits—all other integer data types remain 32 bits. Because pointers are local to each side of the client/server connection and are usually transmitted as NULL or non-NULL markers, the marshaling engine can handle different pointer sizes on either end of a connection transparently.

However, backward compatibility issues arise when you add new data types or methods to an interface, change old data types, or use data types inappropriately. The following topics discuss how to avoid these situations (when possible) and how to design robust workarounds when it is not possible to avoid them.

 

Best regards,

Sean

Answer 2

User753101303 posted

Hi,

And what happens when you just run your app? Do you have an error message? If not which value do you see when showing https://docs.microsoft.com/en-us/dotnet/api/system.environment.is64bitprocess?view=netframework-4.8

.NET 4.x makes easy to create an app that could run both in 32 bit or 64 mode (possibly even using a single assembly). Most often it just works, the common catch being loading external DLLs such as OleDb or ODBC providers using the wrong architecture.

Answer 3

User303363814 posted

It is more useful to explain the problem that you have rather than trying to explain a solution that you want.

What is the actual business problem that you are experiencing?  Eg - "I get this error 'xxxxx' when I run my application" or "my application runs on my development machine but when I use the 'xxxx' method to run it on another machine then I get the error 'xxxx'"

What do you do and what error or unexpected result do you receive?

Answer 4

User753101303 posted

Since then I gave a try to SigCheck and as I suspected I see that AnyCPU dlls are reported as 32 bit (more likely because it uses a 32 bit stub to compile the embedded https://en.wikipedia.org/wiki/Common_Intermediate_Language#Execution to 32 or 64 bit machine code).

https://docs.microsoft.com/en-us/dotnet/framework/tools/corflags-exe-corflags-conversion-tool is inspecting a .NET header to show the true underlying architecture for the DLL and would be better if you want to check .NET Dlls.

So if still interested it would be better to see the direct issue (ie what happens when your app runs, could it just run already as a 64 bit process?) rather than based on indirect (and apparently wrong) findings. 

Answer 5

User-536888146 posted

First of all thank you all for your replies and sorry for the late response.

The reason behind the requirement of 64-bit DLLs is that we are planning to implement a WAF using Signal Sciences on IIS server. And using 64 bit DLLs was a necessity for us. That's why we planned to convert our DLLs to 64-bit.

For now we are planning to go with PatriceSc's advice to just try to run the application on the server with the WAF and check if it works or not.

Thank you all for your help and time. I'll update and share the results here.

Answer 6

User753101303 posted

Humm. To reiterate when writing C# code properly its is compiled to MSIL code which is compiled at runtime to x86 or x64 code; So it is easy in most cases to create a DLL that can run both in x86 or x64 mode (or to create a 32 bit only or 64 bit only DLL without any code change).

Further more it seems weird to me that a WAF would require the app to be in 64 or 32 bit mode (to me it works at the http level, it doesn't plug into the applicarion process).

So please make sure to have an actual problem. For now it seems you try to anticipate problems that are not that likely to really happen.