The wyDay blog is where you find all the latest news and tips about our existing products and new products to come.
Just a quick update to our blog to say a bunch of stuff in coming at the end of this year. Some sooner than later.
Some of it will be obvious. Some of it will be surprising (but if we're honest, the surprising stuff might be pushed back until 2024 for the obvious stuff to make it out "on time").
But that's enough with being cagey. In the meantime, sign up for LimeLM and/or get wyBuild. And we'll see you on our forum if you need help using our products.
This is a short, but long overdue, update to tell you we've extensively tested all of our products with the current pre-release build of Windows 10 (10240), and everything is working perfectly. So if you're using the latest version of TurboActivate and TurboFloat (get the latest versions on your API page), and the latest version of wyBuild, then you'll be able to continue to use the best licensing and updaters with all currently supported versions of Windows.
(And of course, with TurboActivate and TurboFloat, you'll be able to continue to use the best licensing on Mac OS X, Linux, and soon Android in addition to the Windows support).
We'll of course test everything with the final Windows 10 once it comes out.
We keep an up-to-date list of compatibility and requirements on their own pages:
This past week we did major work and expansion to our server infrastructure to support the big features that are coming to LimeLM in the very near future.
The only changes that you will see currently (as of me writing this) is a healthy speed-up for all requests (managing licenses in LimeLM, online activations, deactivations, web API requests, etc.). But visible — and very cool! — features are coming soon.
So, stay tuned for big updates to LimeLM, TurboActivate, TurboFloat, and wyBuild that will be rolling out over next 3 months.
I'm excited! I can't wait to show off our hard work to our growing, loyal, customer base.
In todays article Im going to talk about an interesting problem: detecting .NET assemblies. More than that, Ill be talking about detecting some features of .NET assemblies and how you can expand and mold our code for your own uses. The codes at the bottom of the article, its written in C# and licensed under the BSD license. Go get it.
Ive seen this question pop up in a few different forms:
And the list goes on and on. But this raises the question
We detect .NET assemblies because we respect humans time. Let me explain.
When wyUpdate (our open source updater) installs updates it can do a few things beyond simple patching, registry changing, and file copying. Namely it can:
Which means wyUpdate needs to know whether the executable (or dll) is a .NET assembly, whether its strong signed, and what platform target it is (i.e. x86, x64, or Any CPU).
We could ask the user for every file, but thats such a hassle. Who wants to waste time checking boxes for every exe and dll in their project? Rather than wasting the users time we quickly scan the .dll and .exe files for their details when the update is built inside wyBuild.
Do not use LoadLibrary(), or Assembly.Load() functions to load an assembly in memory to then parse it. This breaks when you have an x86 process trying to a load an x64 assembly (or vice versa).
Instead of using LoadLibrary (or one of its brethren) well just treat the executables as dumb files. That is, just run a simple loop over the file and skip over the unneeded parts. You can check out the C# code posted at the bottom of this article, but you should be aware of 2 resources we used when designing the .NET detection algorithm:
The PECOFF spec gives you the general layout of .exe and .dll files, and the CLI Partition II gives .NET specific features that we detect. Namely, is the assembly strong signed, is it built for Any CPU or x86 alone, and what base version of the .NET framework is it built for (2.0 or 4.0).
Also, when you check out the code, notice how the code handles PE32 files versus how it handles PE32+ files. That is to say, 32-bit assemblies have a subtly different layout than 64-bit assemblies.
If you find this code useful, tell me how youre using it in the comments.
Download the AssemblyDetails C# source. It works with .NET 2.0, 3.0, 3.5, 4.0.
Example usage:
AssemblyDetails ad = AssemblyDetails.FromFile(filename); // ad == null for non .NET assemblies
if (ad != null)
Console.WriteLine(Path.GetFileName(filename) + ": " + ad.CPUVersion + ", " + ad.FrameworkVersion);
else
Console.WriteLine(Path.GetFileName(filename) + ": Not a .NET 2.0+ executable.");
Update 7/3/2010: There was a slight bug in the first version. Re-download the code.