I use Cropper as my primary screen capture utility.  Unfortunately, it will not run on Windows Vista 64-bit (it causes a Bad Image Exception), despite it being built on the .NET Framework.

Having discovered this, I thought “surely, I could not be the only individual who has ran into this issue” and headed to the Cropper Issue Tracker where, lo and behold, I found this item.  The fix turns out to be quite simple: Change the platform from ‘Any CPU’ to ‘x86’, recompile and then replace the installed assemblies.  This fix will also work on Windows XP 64-bit.

The installation directory is <drive>\Program Files (x86)\Fusion8Design\Cropper.  You will need to replace not only the assemblies in this directory, but also those in the plugins sub-directory.

Earlier this year, I began work on a project on which I recommended Microsoft Synchronization Services for ADO.NET for use as our synchronization solution.   Our application is a desktop (WinForms, no WPF -  maybe more on that decision later) application that needs obtain and work with both reference data and bi-directional data (i.e. data created/updated by the user or the server).  The database we are exchanging data with happens to be Oracle, so a solution leveraging SQL Server Merge Replication was out.

Given that my Oracle skills were, at that time, rusty at best, I thought I would check out the example that Rafik posted for using Sync Services with Oracle.  Fair enough.  Once I got it working as-is, and before I began writing code against our database, I thought I would verify that it worked with ODP.NET. 

Why ODP.NET?  We were looking to leverage some of the capabilities available in that provider vs System.Data.OracleClient.

I changed out my references, made the necessary code changes and attempted to run.  Shortly after I invoke a sync, I receive the following error:

Type 'Oracle.DataAccess.Types.OpoDatCtx' in Assembly 'Oracle.DataAccess, Version=2.111.6.20, Culture=neutral, PublicKeyToken=89b483f429c47342' is not marked as serializable.

My initial reaction was to wonder what I had done incorrectly, or had forgotten to do.  I checked the code. Thrice.  Nothing missing. Stymied, I posted to the Sync Services for ADO.NET forum with suspicions that OpoDatCtx was internal to ODP.NET.  Sean Kelly from Microsoft replied to my query.  In sum, Sync Services was only ever intended for use use against Microsoft-implemented/shipped ADO.NET providers.

As (thank you, Reflector), OpoDatCtx is (as I suspected) an internal type and one I could not convert, this meant I had two option:

1) Return to using System.Data.OracleClient and deal with any ‘shortcomings’ compared to ODP.NET.
2) Dump Sync Services so that we could use ODP.NET, but roll all the sync code from scratch.

As you might have guessed, I chose option 1, and Sync Services is working swimmingly against Oracle.

Check it out!  What started as a joke on Twitter has blossomed into a great community-inspired and contributed virtual conference.  There is some great content being presented.   http://notatpdc.com/presentations/

Visual Studio® 2005 Team Suite SP1
http://www.microsoft.com/downloads/info.aspx?na=22&p=1&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3dbb4a75ab-e2d4-4c96-b39d-37baf6b5b1dc%26DisplayLang%3den

Visual Studio® 2005 Team Foundation Server SP1
http://www.microsoft.com/downloads/info.aspx?na=22&p=2&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3da9ab638c-04d2-4aee-8ae8-9f00dd454ab8%26DisplayLang%3den

Visual Studio® 2005 Express Editions SP1
http://www.microsoft.com/downloads/info.aspx?na=22&p=3&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d7b0b0339-613a-46e6-ab4d-080d4d4a8c4e%26DisplayLang%3den

A co-worker noted that you may need to follow the workaround detailed in KB925336 to get it to install successfully. (thanks, Matt!)

Hey you!  Going to CodeMash?!?   What's that, you don't know what it is?  Let's find out:

CodeMash is a unique event that will serve to educate developers on current practices, methodologies and technology trends across a variety of platforms and development languages.  Java, .NET, Ruby, and PHP anyone?

Even better is that CodeMash is held at the Kalahari Resort  (596 beautifully appointed African-themed guest rooms and suites) in Sandusky, Ohio. What a great way to escape winter weather in the Great Lakes region!

Ok, enough cheesy sales pitch.. you want the goods, eh?

How about more than forty-five sessions across areas like:

• Architecture (SOA, WS*, Interoperability and more)
• Desktop Dev (Smart Clients, client/server, and any standalone apps on your favorite platform)
• Web Dev (Web services, AJAX, frameworks, and all sorts of browser magic)
• Methodologies (Help you do it faster, better, cheaper, and with less pain)
• Mobility (devices, content distribution, social networking, and more)
• Languages (see what's new and nifty with C#, Python, Ruby, Java, PHP and more)

Check out the session list (and those are just the confirmed ones, more sessions still being added, so check back often!).

Speakers?  How about Bruce Eckel, Neal Ford, and yes, Scott Guthrie.

Register now!   Register by December 18, 2006 and registration is only $99 and get a guaranteed room. Time and rooms are running out!  Conference registration, meals, hotel room for only $349! 

CodeMash - Making it all work together!

I recently found some very sweet modules that Scott Watermasysk has put together for Community Server 2.0.  Here’s the thread on them: http://communityserver.org/forums/518790/ShowThread.aspx  The download link is in the first post. I’m particularly stoked about the MetaBlog Extender which allows  should allow* me to declaratively set things like the name of my post and the categories in the body of the post.  Very handy for naming my posts from within BlogJet.

..and yes, I recompiled them under 2.0.

-Nino

*Unfortunately, this doesn’t work on my production (hosted) server in a medium trust environment. It doesn't work because metablog.ashx doesn't work in a medium trust environment.

Last night I was reading the InfoWorld that came this week, and read Chad Dickerson's column (CTO Connection), the topic of which was The great IDE debate. 

InfoWorld is a Java shop; as we all know, there are a bevy of Java IDEs to choose from, many of which are open source.  Their dev team does not use an IDE; they use text editors (UtraEdit-32, vi, and Emacs).  Mr. Dickerson queried his team as to why they had chosen to avoid IDEs; here's what they had to say:

 They thought the level of abstraction that visual IDEs brag about was more a detriment than a benefit. One of our developers compared building code in an IDE to using a WYSIWG editor to build Web pages — doing HTML by hand results in cleaner pages, and you know exactly how they work when you’re done.

Hmmm. I'm going to skirt the direct IDE vs. Text Editor argument (I will say that I favor an IDE) for now, and look at a sub-issue.  So your team has elected to avoid the IDE. Fine, but multiple text editors within the team?  Bad idea, IMO. 

Two years ago, I was working with a customer as they embarked on their first .NET application (they were a Java shop), and they were of the text-editor persuasion.  For their .NET project (WinForms) they were using Visual Studio 2002 of course, but when I discussed with them their pain points in their current (Java) development environment, one of their items was that each developer was using a different text editor.  The problem here was that each text editor affected the source files differently, and not every text editor could be configured to affect source files similarly, so each developer was often dealing with anomalies  from another's editor. 

I see a simple solution to this: mandate a standard toolset with a standard configuration.  I hear the cries of "but I work more efficiently with <insertnamehere>" and "I hate using <insertnamehere>"  I'm somewhat apt to give in as long as developer X's text editor can be configured to treat the source file like developer Y's text editor; however, that would violate the 'standard toolset' rule.  I believe strongly that everyone on the team should have an identical development environment; an identical configuration eliminates a lot of possible issues.

Thoughts on IDE vs Text editor?  Multiple text editors on a team (if not using and IDE)?

-Nino

My team ran into the aforementioned issue today.  Grrr.  Two of us spent some time trying to resolve this. (MSKB article, fyi)  Our solution has eleven (11) projects in it, some .exe, some .dll, all WinCE.  I ended up removing one project from the solution, deleting it (saving all the .cs, of course), re-creating it from scratch, and then re-adding the classes to it to get us back on track.  I'm curious as to what others have done to resolve this spurious error...

-Nino