EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Problems when building for .NET 3.5

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
Posted: 11/07/2012 06:32:17
by Ivan Hristov (Standard support level)
Joined: 10/26/2012
Posts: 16

I recently tested the trial version of your components and everything was running fine, but now seems that I have confronted some problem with earlier versions of .NET Framework.
For backwards compatibility I need to implement signing in a project, targeted for .NET 3.5.
I add reference to SecureBlackBox.dll, which is contained in C:\Program Files\EldoS\SecureBlackbox.NET\Assemblies\NET_20. It compiles, but during startup, an exception appears, saying:
Could not load file or assembly 'SecureBlackbox, Version=, Culture=neutral, PublicKeyToken=5a62fa96d0ac431a' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

I thought it might be related to some inconsistency in trial version, so I didn't investigate further. Besides, all is running well in .Net 4.0 projects.
Today I received the license key of the library we purchased and decided to give it a shot. I uninstalled the trial version, restarted (just out of superstition :)) and installed the new package. During the installation, I made sure that I check .NET 2.0, 3.0 and 3.5 options.
After installation was finished, I reloaded the project, double-checked the reference paths and now the error message is slightly different:
Could not load file or assembly 'SecureBlackbox, Version=, Culture=neutral, PublicKeyToken=5a62fa96d0ac431a' or one of its dependencies. The system cannot find the file specified.

Just to be sure that the issue is not related to the project, I made a very simple .NET 3.5 project - just a winform with one button, which initializes the library:
SBUtils.Unit.SetLicenseKey(--license key--);

but still the same error appears. Of course, the DLL-files are there, no restrictions or user privileges are set, so I really do not understand where the problem could be.
When I change the project target framework to 4.0, everything runs fine - both with assemblies from NET_20 and NET_40 folders.
Can you tell me where the problem could be?

Thanks in advance,
Ivan Hristov
Posted: 11/07/2012 06:36:56
by Vsevolod Ievgiienko (EldoS Corp.)

Thank you for contacting us.

Try to add assemblies to the project manually and set CopyLocal to 'true' for each assembly. Most likely wrong assemblies set is loaded during project startup.
Posted: 11/07/2012 06:49:44
by Eugene Mayevski (EldoS Corp.)

Windows creates several copies of assemblies in GAC. Uninstall script attempts to remove them all, but chances are that some copy is still present. It's possible that the application loads 4.0 assemblies.

Sincerely yours
Eugene Mayevski
Posted: 11/07/2012 06:53:40
by Ivan Hristov (Standard support level)
Joined: 10/26/2012
Posts: 16

thank you for the quick answer.
That's what I did: I referenced the assemblies manually, tried to set CopyLocal to true/false, but the exception is still thrown.
I use VisualStudio 2010, not 2005/2008, but I highly doubt that it could be a problem.
Posted: 11/07/2012 06:54:40
by Eugene Mayevski (EldoS Corp.)

This can be a problem in fact. Did you try to check the application on other system with only .NET 3.5 installed?

Sincerely yours
Eugene Mayevski
Posted: 11/07/2012 08:01:31
by Ivan Hristov (Standard support level)
Joined: 10/26/2012
Posts: 16


Yes, I tried and it worked fine (on a system with only 3.5 installed).
I kinda solved the problem. Seems that VS2010 caches the references (or the assembly files), even if I set "CopyLocal" to true. But if I start the application from /BIN folder, it works. After system restart, the project started to run fine in VS2010 too.

Problem solved (I guess). Thank you for your help.
Posted: 11/07/2012 08:15:14
by Eugene Mayevski (EldoS Corp.)

Thank you for providing the solution, as the problem happened from time to time with no definite solution (until now).

Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.



Topic viewed 1009 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!