This project has moved and is read-only. For the latest updates, please go here.

alpha release does not load with VS 2005 Pro

Dec 3, 2008 at 8:20 PM
The readme.txt file says it requires VS2005 and .NET Framework 3.5. I have both installed on WinXP. The solution file version is 10.0 and VS 2005 throws an error saying it cannot load the solution file because it is the wrong version. I tried loading in C# 2008 Express (since I had it handy), and it throws an error saying the express version of VS does not support solution folders. Either there is an error with my config or the alpha release needs VS2008.
Dec 3, 2008 at 9:13 PM
Information in Readme.txt is outdated, sorry for this, will fix in next checkin. It should be VS 2008. As for solution file, I'll remove solution folder with next checkin - they are not critical, didn't know about this problem with VS Express - thanks for pointing it out. For now, you can recreate the solution file and add the projects manually. Or maybe edit the solution file directly?
Sorry again for inconvenience
Dec 3, 2008 at 9:56 PM
Actually, this project is so fun that it has convinced me to move to VS2008. I've been holding off because SQL Server 2005 uses VS2005, and I'm going to be using SS2k5 for another few years at least. (I am a DBA for a hospital, and our vendors make glaciers look speedy when it comes to adopting new database systems.) But, Irony makes it so easy to play around with compiler designs that I'll adopt what it needs. My interests are in adding .NET code to a database server without having to load a new assembly everytime I make a change. There are times when T-SQL just doesn't do what I need to do, but writing a C# program is more effort than doing it manually. I'm going to be looking at Script.NET as a way to get the functionality of the .NET framework when I need to do stuff outside SS from within SS, e.g. text file importing and exporting. Plus, I'm an old computer science geek who always thought designing compilers was cool. :-)

You've created something incredibly cool that I think has the potential to be a game changer when it comes to adding dynamic functionality to applications. Thanks for the work you've put into this.
Dec 3, 2008 at 10:17 PM
Edited Dec 3, 2008 at 10:28 PM
Thanks for your praise - really appreciated.
As for using it inside SS - please read an earlier discussion "Adding assembly to SQL Server 2008". Looks like it is not so easy, at least loading Irony as "safe" assembly. I've tried to tweak things inside Irony to comply with some "very strict" requirements of SQL server, and finally had to give up. It turns out the HashSet generic type from .NET libraries (set of values or objects) that I use throughout Irony - it turns out it is "unsafe"; so I had to give up. You still can load it as unsafe assembly, and if you're ok with this (oh, you're DBA - so it's your call!) - then have fun!
Dec 4, 2008 at 10:19 AM
>It turns out the HashSet generic type from .NET libraries (set of values or objects) that I use throughout Irony - it turns out it is "unsafe";

might be a tip
if you use linq to objects you won't need hashset anymore.

at least i was able to get rid of all my code that relied on hashsets.

- lm
Dec 4, 2008 at 1:07 PM
I could certainly use plain lists or dictionaries instead of hashsets and  use linq to simplify some search code, but that would bring a serious performance hit. When I switched to hashsets I got almost two-fold performance improvement on initialization. Giving it up - not worth it I think
thanks for the tip anyway
Dec 4, 2008 at 4:14 PM
I saw the thread on SQL Server 2008, and I think I understand the problem. One advantage of being the senior DBA in charge of the servers is that I can make the decision about permitting "unsafe" assemblies. Also, I'm going to try to encapsulate your assembly in one that only exposes limited functionality to see if I can "hide" the parts that SQL Server doesn't like. I'm thinking I may have to do that anyway to keep from having to install all of .NET 3.5 on each server.

My time to tinker with new stuff comes in cycles, and it may be after New Year's before I can really dig into figuring out how to make it work on SS. I'll let you know if I find a better way than forcing SS to accept an "unsafe" assembly.

Btw, one thought on leblanc's suggestion: hash sets are easy to implement with generics, so one path of exploration would be to write a replacement for .NET's hashset that meets the stricter requirements. That is my plan B if my first plan doesn't work.
Dec 4, 2008 at 4:36 PM
One additional thing to add to the notes is that the unit testing components need to be installed for the Irony.Tests project to load.
Dec 4, 2008 at 6:00 PM
Answering all at once.
About hiding Irony - I doubt it would work, because I think SQL server scans all used types, and all the chain through the hierarchy, so it will find the offending Hashset anyway.
Implementing replacement for hashset - I would certainly consider it if only I was sure it is the last one. As the story was going the SQL server was giving rejections one at a time, and after I was fixing one, it would come up with the next one. (I didn't try it myself, another user was reporting me stuff as I was fixing Irony) So I'm afraid the Hashset is not the last one. At the same time, I hope MS fixes this some time in the future, because clearly the thing is not right: a general-purpose innocent type from System.Collections.Generic namespace is rejected by SQL Server for security reasons. So I would suggest to wait and see... Especially considering the fact that Irony has a lot of other outstanding issues that need to be done to implement MUST-BE functionality.
Testing components - sorry folks, I wasn't aware about problems like these. I myself enjoy full-featured VS 2008 and never had a chance to try a "downgraded" environment. I know it's not fair for fellow developers, but I'm afraid I won't be able to get to this. Barely find time for mainstream features. I hope there are some workarounds, with full sources at hand. But if you or somebody else who has Express edition writes down some "readme" recipes for downgraded environment - I would be happy to add these to readme file, with full credit to the author.
Dec 5, 2008 at 5:04 PM
Edited Dec 5, 2008 at 5:04 PM
I wonder if there is a simpler way..

Maybe it just needs to be signed

Example I recently saw a project here on codeplex that when the project is built it is automatically signed:
check out Properties folder and find *.snk

Maybe all it needs is a [Security] attribute on a class.. .some type of AOP microsoft has.

To avoid all this speculation someone that has paid microsoft support with their subscription should call and ask:
"What are the requirements to create a safe assembly for sql server?" 
And give an example of this project.

Lastly, if microsoft does agree that HashSet is the problem then create a new configuration using "Configuration Manager" and copy the release template and add a "conditional compilation symbol" called SAFE_ASSEMBLY

In your code you would have:
linq stuff


Dec 5, 2008 at 6:18 PM
Edited Dec 5, 2008 at 6:20 PM
It is not signing, and security attribute cannot fix it. Here's a copy of Hashset header from MSDN:

[HostProtectionAttribute(SecurityAction.LinkDemand, MayLeakOnAbort = true)]
public class HashSet<T> : ICollection<T>, IEnumerable<T>, ...

It is this MayLeakOnAbort=true that SQL Server does not like. Note that this is MS developers who put this value on a class, and nothing we (class users) can do about it.

As for using conditional compilation - that's adding a lot of complexity to the code - I would say introducing quite a mess. Not worth it IMHO. Again, who garantees it is the last bump on the road?!
I would expect (ask?!) MS to fix this in the future...

Dec 6, 2008 at 5:46 AM
Here is another idea: (improvement on conditional compilation)

create a
which centralizes the conditional compilation variable.
return mono's version with cleaned up pieces causing problems

return a copy of microsofts hashset that with applied attributes but extends or implements IHash

All your code should be changed to:
IHash hashset = IHashSetFactory.GetInstance();
hashset.nochangeinyour your code usage only initialization.

this could be tested by someone that really wants to create a safe version for sql server.. I use postgresql so it doesn't help me.
Just some thought for royalhale, Datawrangler,
and anyone else with these problems.