Show Blogger Panel Hide Blogger Panel
Alex Yakunin

October 18, 2009

Issues in v4.1 RC


Unfortunately, we identified a set of serious issues in DataObjects.Net v4.1 RC:
  • CopyIndirectDependencies.targets packed there contains a bug leading to an error on building "Rebuild" target, if there are any project dependencies in the project it is imported from (i.e. there are references to projects, but not just to .dlls). So "Rebuild" in VS.NET does not work in this case. Imagine, we've been using this .targets file for about a month, and noticed this just on this week - it seems none of us uses Rebuid, since Build works perfectly with our projects ;) Alexey Kofman said he faced an issue with Rebuild before, but being in hurry, we didn't pay appropriate attention to this.
  • Our new DataObjects.Net.targets fail if any version of PostSharp is installed on your machine. I mentioned it should be uninstalled, but we understood that people does not pay attention to this. Moreover, it's quite bad if DO4 conflicts with installed PostSharp, especially taking into account the fact that a bit earlier we require you to install it.
  • Since now we copy all .pdb files into bin folder, you may get a set of breaks on exceptions thrown and caught inside Xtensive.Core during Domain shartup. This is normal - we never use exceptions in normal operation flow, but in some cases .NET does not leave us a choice. E.g. when AssociateProvider tries to instantiate candidate generics, it's impossible to make .NET to notify us this is not possible without an exception (e.g. if "where T: ..." condition fails for a particular generic). So we catch it and try the next one in sequence - that's what AssociateProvider implies. Implementing all these checks manually is pretty complex, so we don't do this for now. But it's not a good idea to copy .pdb and make VS.NET to show all of them as well.
  • A debug code writing assemblies with built Tuple types is not commented out in Xtensive.Core project sources. So Xtensive.Core tries to create .dll files in bin folder, and if the process had no write permission there, it fails.
Fortunately, there were no any serious issues related to runtime behavior - continuous integration and testing we run almost immediately exposes them. As you see, the issues I just mentioned are related to build and installation process, which isn't covered by our test suite. That's why we got them...

Ok, now the good news:
  • All these issues are already resolved
  • New v4.1 installer will be published today.
I'm really sorry for this incident. We'll identify all the persons that downloaded v4.1 RC and notify them personally - likely, this build was a real disappointment for many of them.