Greetings Hackers,
I wanted to get some feedback from the community. In an effort to
implement a sensor for Visual SourceSafe, I've successfully created a
native .NET sensorshell using IKVM (http://www.ikvm.net).
Here is some feedback on the compilation/usage for those who are interested:
-- There are a number of warnings that are generated because some sensor
classes are included in sensorshell.jar despite the lack of dependent
JARs. No matter -- none of this code is typically ever called. However
don't call it yourself!
-- The biggest challenge is loading SDTs, since the conversion of
"loading from a JAR" simply didn't work. I'm not sure if there is a .NET
equivalent capability, but regardless IKVM doesn't support it. I
modifed SDTManager to load from ${user.home}/.hackystat/sdt...(more on
this below).
-- You must add a few assemblies to your GAC (see IKVM website for
info). Depends on GNU Classpath (open-source Java library)...not sure if
this has other negative ramifications yet...
-- In your app, you'll need to write a quick converter between .NET
DateTime and java.util.Date. (I'd be happy to contribute this too).
Advantages
** No dependencies on JVM/JARS.
** Simply include sensorshell.exe as a reference to your project in your
.NET IDE.
** Supports all the features with full control of the API, including the
usermaps stuff.
** sensorshell.exe runs from the command-line just as sensorshell.jar
(one small issue with the version number display in the command-line
version)
SDT Loading
As mentioned above, I needed to make changes to Hackystat (SDTManager)
to make this viable. What do people think about optionally loading SDTs
from .hackystat/sdt? Any other suggestions? Is this an acceptable
change to get native .NET support? I'd be happy to contribute/share my
code although it is just a hack right now.
If anyone would like the EXE / code, let me know. Also, the SourceSafe
sensor is nearly complete. If anyone's interested, let me know as well.
Thanks,
Todd
