Hi, Todd, I am glad to hear that someone is serious about coverting sensorshell.jar into native .net code.
Probably, you are aware that we have implemented a .net wrapper for shensorshell.jar, and it's used in VisualStdio.net and ms office sensors. When the .net wrapper initiates, it creates a java subprocess "java -jar sensorshell.jar", and redirect it's stdout/stderr/stdin. Whenever the wrapper wants to send data, it writes to stdin of the java subprocess, it gets the feedback by reading stdout/stderr. Of course, we have high level wrappers in C# that send particular type of sdt data, such as Activity, and thus shields the client of underlying details. The wrapper itself is in a dll, and can be used in any project. The advantage of this scheme is its simplicity. The disadvantage is that you have to bear the overhead of a JVM. The advantage of IKVM is that it gets rid of JVM completely. But it has its own problem as noted by Philip, and the technology is still in beta. My personal view (this may not represent the entire Hackystat development group) is that both approaches are short-term. In the long term, I want to have a pure .Net sensorshell. It's not difficult to replicate the functionalities (soap communication, local off-line storage, strongly typed metric data from sdt xml), except that it takes some no-trivial effort. We never have had a strong demand for a pure .Net sensorshell, and I never have the time to work on this myself. If you have the demand from your client, and the resource meet the demand, I am glad to provide technical assistance. Cheers, Cedric Todd Olson wrote:
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
