Archived Forum Post

Index of archived forum posts


Wrong version showing in Visual Studio

Sep 01 '16 at 14:41

I'm trying to upgrade to ChilkatDotNet46.dll and no matter what I do, Visual Studio shows version I verified that my reference is pointing directly to version of ChilkatDoNet46.dll, viewing the properties on that file shows, but if I create a blank WinForms application and add that file directly to my 64bit solution, Visual Studio shows it as

I wanted to see exactly what version of the DLL was being loaded so I had the following code to to a MessageBox and it showed, not which is what I have referenced in the project.


Any help would be GREAT, thanks.



I have not used the Chilkat tools in .NET yet.

Did you register the new DLL in to the GAC, or just copy over the previous?


It looks like my VS2015 reports my DLL as .52 although the file properties reports .55 with an MD5 of EA00A78FB875B0E1DD766250E12F9FC4. I don't think I've noticed a mis-match before. I don't see historical checksums on the site to see which version that really is.

Is this in a project in which you were previously using .52 and you are trying to do an in-place upgrade to .58 by just swapping the DLLs?

Have you verified the MD5 shecksum of the DLL that you have referenced? 55fdb01f8162b9732c35b4c469ba175d for the 32-bit and 8385f422c4614e7574e4af3c6f492ba9 for the 64-bit versions of .58.

If you have a long list of references, are you certain that a reference to a .52 version does not remain?

Would a Clean/Rebuild of the project help?


I've tested with a simple brand new WinForms project and added the DLL directly to the solution and it reports .52. However, it sounds like your VS is exhibiting the same behavior. I'm not sure where it's pulling in the .52 from, my DLL's file properties also show the correct version that I am expecting (.58). My actual DDL's file checksum matches the expected value as well.

My biggest concern is that I'm not actually utilizing .58 in my app but I don't see how that would be possible, I've never used .52 before.


Give it a shot accessing a method or property that is only in .58.

Right of the bat, I see that several of the objects, including MailMan and Crypt2 have a new AbortCurrent property that was just introduced in .58 and lend themselves to some pretty simple test code. If you try to access their AbortCurrent and it knows what you are talking about, it's probably a safe bet that your VS really is referencing .58.

public bool AbortCurrent {get; set; } Introduced in version When set to true, causes the currently running method to abort. Methods that always finish quickly (i.e.have no length file operations or network communications) are not affected. If no method is running, then this property is automatically reset to false when the next method is called. When the abort occurs, this property is reset to false. Both synchronous and asynchronous method calls can be aborted. (A synchronous method call could be aborted by setting this property from a separate thread.)

Until someone from Chilkat comes along to address the discrepancy between the version reported by VS and the Windows-properties reported version, I'm not sure what else to look at.

Have you scrubbed any/all other ChilkatDotNetXX.dll files from your machine, either by deletion or renaming to make sure it couldn't be pulling one from elsewhere?


The version to trust is what you get programmatically when you access the Version property. For example, in C#:

string v = sshTunnel.Version;

If a different version shows when right-clicking on the DLL, then it's just version resource that didn't get updated properly (and if so, will be fixed in v9.5.0.59).


Thanks, Chilkat.

The version of ChilkatDotNet46 that I am using reports .55 from the Windows properties, .52 in VS2015, and .56 in the Crypt2.Version property! Presumably OP's version is the correct .58 if that is what he has verified via MD5 sum and referenced in VS.


Thank you, everything is looking good when I check the version via the method in the library!