I recently was playing around with Plastic SCM, since after all these years the perfect source control solution continues to evade us.

Overall, so far Plastic has been quite good. However, I did run into a silly user-friendliness issue that I thought I would share.

The message "The authentication or decryption has failed: server:port"

can occur for a couple of reasons.. I was running into it because the certificate hostname did not match the server hostname.

By default, Certificate Hostname is generated automatically when the Plastic SCM server is installed and matches the machine name.

Server Hostname is the address you specify in the Plastic SCM Client configuration.

I received a number of questions on how to configure ccScreenSpy so that the screen captures are not emailed, but are simply saved to disk.

The configuration change is actually quite simple - simply do not specify SMTP server in the configuration (ccss.exe.config).

Under the hood, the thread responsible for sending the email would throw an exception but it would get caught.. Well, I thought this was a little dirty, so I updated the code to actually check for the presence of these settings, and if they do not exist, the application will not even attempt to send an email.

Another request that has come up was to allow emails over SSL (like GMail). I added a new setting to the email configuration called "use_ssl". Set it to 'True', if your SMTP server expects communication over SSL.

Hope that's useful. Update is available here.

Cheers!

I ran into a funky issue with the interaction between SVN, Visual Studio and my brain recently. I was trying to commit some changes I made to a project and during the commit got slapped with something like this:

I did some Googling, tried some creative suggestions here, all somewhat unsuccessful. 

Eventually, I started looking at the nature of the change that I made, which among other things included addition of a service reference to a project. However, I realized that it's not exactly what happened. I didn't add a service reference, but instead I deleted a service reference and then added it back..

There are a number of reasons why you may want to grab a screenshot of your Android app. In Eclipse, DDMS perspective provides an easy way to do it via the UI:

However, UI features like this are hard to automate and sometimes it can be handy to be able to grab the screen from command line via a script. Welll.. 

Android Tales pointed me in a direction of the old platform source that claimed to do just that. The newer source versions do not include the ScreenShot.java utility, so I had to grab an old one here. So I followed the directions and got the old stub here, added ddmlib and Screenshot.java classes to the same project, compiled, ran in on a loaded AVD with v2.2 and...

Do you remember when batch scripting was cool? 

Yeah, me neither..

But not because it was never cool, no. It's just because some time between then and now I went to college and partied a good amount, which undoubtedly had a negative effect on my ability to recall things. Anyway…

Despite of what some people, who should probably stick to "overseeing license compliance",  might think, the apps from various Android markets have shown ability to do some shady things and the expectation that the underlying app markets will catch and remove those apps themselves is a solid case of hubris. (Whether malware infestation is a case of PEBCAK or a platform design flaw is really irrelevant). As such, it is quite useful to be able to capture application behavior in some sort of automated fashion, so it can be analyzed. Needless to say, this is also useful for automated testing and other such nonsense.

Ok, well first, the title of this post is deceiving. Really this post is about converting a byte array to a printable/displayable string in C#. The problem is that if you have an arbitrary byte array, say, representing an object from a stream or something, it may contain characters that are not actually printable or visible (i.e control characters) and when you try to use Console.WriteLine or anything of the sort, you may hear beeps or see weird shapes.

Anyway, I was coding a tool that allows inspection of objects in an MSM queue, and as such needed to somehow display a binary object. I wanted to do something similar to the Visual Studio Memory Watch debug window, where I showed the bytes that were "showable" and substituted a period ('.') for bytes that were not. Easy enough, here is the code snippet:

I love the expression "up-to". When marketing folks die and enter the afterlife, presumably it's up to 100% heaven. The nice thing about "up to" is that it encompasses the null set of whatever range it is cast upon. Up to 99% success rate could very well be 0% success rate since it satisfies the idiomatic condition.

Anyway, so I was coding in Java the other day and ran into a decent candidate for the WTF files.

I was doing this un-encryption thing, where I was reading a file and un-encrypting it using the specified key. Pretty basic stuff.

I was using the CypherInputStream class to read the file stream and decrypt it. I user CypherInputStream.read method and everything was dandy until in my testing I noticed that a portion of the file remained encrypted.

I ran into this error a couple of times when trying to launch debug for an Android application in Eclipse. In all the cases I completely forgot what I had to do to fix this and this thread has conssitenly led me towards the solution.

However, not all the way. For some reason, doing a project Clean did not remove the jar file for one of the libraries in the workspace and that was causing an issue in another project that referenced the library.

In any case, for me the solution has been to simply search the workspace directory tree for *.jar, and remove the Jars for any of the projects that are about to be built (i.e. keep any 3rd party Jars for which no source code would be compiled.) So far so good..

Cheers!

One of the many cool things about WCF is that it abstracts network communication into the lower layers of the framework and leaves us developers to deal with the actual data for our applications instead of the nitty gritty of connection handling and data casting.

Operation Contracts can define parameter types explicitly and that works as expected. But what's super neat is that a service method can define a parameter of a generic type (i.e. object) and the service can still auto-magically figure out the underlying type and cast the object appropriately as long as the ServiveKnownType attribute of the service contract is properly specified...

Well.. almost.

Recently, I was working with an Android client that interfaced with a WCF service. I used JSON to encode and transfer that data. Everything was great, until I called one of my service methods that had a generic parameter:

[OperationContract]
string DoSomeStuff(int id, object inputObject);

I should mention that I already had a .Net client (that DID NOT use JSON) for this service and everything worked great. However, calling this method from Java resulted in the following exception: