Determining the target .NET Framework version of a .NET assembly

To determine which version of the .NET framework an assembly supports, you can use ILDASM.

Open up a visual studio command prompt, and type the following:

ildasm.exe C:\Yourdll.dll /metadata[=MDHEADER] /text /noil

You’ll get a large amount of indecipherable data, but right at the top, you’ll see something to the effect of

// Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, version: v4.0.30319

where the highlighted piece gives you the supported version.

Alternatively, you can just open ildasm (just type ildasm at the command prompt), and open up the dll – you can see the metadata version right at the top by double-clicking “MANIFEST”:

Useful!

Moq BadImageFormatException with NUnit

I ran into an issue today running a unit test where I kept getting a System.BadImageFormatException on the test dll. I incorrectly assumed this was NUnit - after digging around a bit I worked out it was actuall Moq that was the source of the problem.

The return value of the object being verified existed in an assembly that was not being referenced by my test project, and Moq was falling over. Adding the reference sorted out the problem.

The exact error I encountered was:

Test.MyLongNamespace.MyTestmethod: System.BadImageFormatException : [C:\Users\matt salmon\AppData\Local\Temp\nunit20\ShadowCopyCache\9748_634255057586445703\Tests_64256578\assembly\dl3\5181e02b\57ddb865_7585cb01\MyAssembly.DLL] The signature is incorrect.

Rebuilding SQL Server Indexes

I've always used cursors to rebuild indexes in SQL Server, like so:

USE YourDatabase

DECLARE @tableName varchar(255)
DECLARE cur CURSOR FOR

SELECT table_schema + '.' + table_name 
FROM information_schema.tables
WHERE table_type = 'base table'

OPEN cur

FETCH NEXT FROM cur INTO @tableName
WHILE @@FETCH_STATUS = 0
BEGIN
	DBCC DBREINDEX(@tableName,' ',90)
	FETCH NEXT FROM cur INTO @tableName
END

CLOSE cur
DEALLOCATE cur

However, I discovered a much easier way to do it today:

sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?')"

This is an undocumented stored procedure that I didn't even know existed until this morning. The cursor route is still useful for when you want to exclude tables, but dang....I wish I'd known of this earlier.