Nybbles, Bytes and Words

Localized WPF Applications

2009-03-23T12:20:00.010-05:00

Have you every worried about how you were going to localize your WPF applications?

The WinForms localization model is fairly mature, built into the designer, and utilizes satellite assemblies, that allow for post-build extension of your application. This has many advantages, including being able to farm the localization off to third parties, without requiring them to recompile the original application.

The WinForms model also lead to concise class wrappers and tags for your localized data. That made it easy to access both in the designer, and in the code-behind.

WPF doesn't seem to have the whole localization concept fully baked at the moment. In my opinion LocBaml is to oppresive. Requiring you to spread UID's throughout every XAML document you have, then manually edit every one of them to fit into the planned language.

I just want to localize the words. Can't I use the old satellite assembly approach, for string tables instead of the embedded pages (i.e., BAML resources)?

Yes you can. First decide if you even want the XAML to even be in your satellite resource assemblies. Microsoft says to add the tag into the project file. But, you can localize string tables without doing this.

In your project, add a .resx - "Resources File" (I prefer doing this instead of using the existing Settings file - for separation).
[example: Properties\Resources.resx]
Open the resource file, and change the access modifier to "Public".
Add additional "Resources Files" at the same level, in the same folder. Inserting the appropriate localization code into the name.
[example: Properties\Resources.de-DE.resx]
Clear the Custom Tool field in the Properties window for each of these files.
Open your XAML file and add a reference to the class wrapper namespace.
[In this case WPFTest.Properties]
Then you can go ahead and use elements from the resource string table directly in you XAML

XAML:

<Window x:Class="WPFTest.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:res="clr-namespace:WPFTest.Properties"
    Title="Window1" SizeToContent="WidthAndHeight">
    <StackPanel>
        <Button Name="button1" Click="button1_Click">Button</Button>
        <Label Name="label1" Content="{x:Static res:Resources.TestString}" />
    </StackPanel>
</Window>

CS Code:

        private void button1_Click(object sender, RoutedEventArgs e)
        {
            Properties.Resources.Culture = new System.Globalization.CultureInfo("de-DE");
            Window1 wnd = new Window1();
            wnd.Show();
        }

Note: You need to set the culture for the resources (if you wish to override the current system settings), before you show the WPF window.

SQLite A Good Alternative

2009-03-22T18:46:00.007-05:00

In the past I have talked about SQL Server Desktop Edition and VistaDB..

I've really been searching for that perfect - elusive, small, embedded, free database. Something that doesn't need an installation, supports encryption and just works. Especially in C#....

.Net is capable of xcopy deployment, and it would be nice if my database could go with me..

I have been leaning toward SQL CE (especially 3.5). It meets most of my requirements (you can copy the dll's for private deployment - and don't need to install)..

But, I think I found a better candidate: SQLite!.

And it is already inside of some things you are probably already using:

Adobe (Photoshop Lightroom, Air, possibly Acrobat Reader)
Apple (Apple Mail, Safari, possibly iPhone, and iPod touch)
Firefox
Google (Google Gears, Android)
McAfee
Microsoft (maybe in a game?)
Philips (mp3 players)
PHP
Python
REALbasic
Skype
Sun (Solaris 10)
Symbian
Toshiba

I have been playing with it for a while in Visual Studio 2008, and am very happy with what I am seeing. The ADO.Net provider gives very clean integration. I am having no problem accessing my data either through the Server Explorer, Direct Connections, LINQ, or even ADO.Net Entity Framework. It is fast, small, and has encryption support (the ADO.NET provider version -link provided below- includes 128 RC4 encryption).

Of course there are a few things to work around. SQLite itself is written in C, and the ADO.NET provider is a managed wrapper around the compiled code. So although .Net can target AnyCPU, there are flavors of the managed wrapper for x86, x64, Itanium, and ARM. Fortunately .Net seems to utilize late binding, and you can figure out your processor architecture and copy the correct DLL into place in time for your app to run properly.

SQLite Home Page
System.Data.SQLite ADO.NET Provider
SQLite Admin - UI Management Console

An example of copying the correct DLL in place:

    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);

            try
            {
                FileInfo fi = new FileInfo(Assembly.GetEntryAssembly().Location);
                string strSource, strDest = fi.DirectoryName + "\\System.Data.SQLite.dll";
                if (Microsoft.Build.Utilities.ProcessorArchitecture.CurrentProcessArchitecture == Microsoft.Build.Utilities.ProcessorArchitecture.AMD64)
                {
                    strSource = fi.DirectoryName + "\\System.Data.SQLitex64.dll";
                }
                else
                {
                    strSource = fi.DirectoryName + "\\System.Data.SQLitex86.dll";
                }
                // Copy the correct dll in place
                if (!File.Exists(strDest)  new FileInfo(strSource).Length != new FileInfo(strDest).Length)
                {
                    File.Copy(strSource, strDest, true);
                }

            }
            catch (Exception exc)
            {
                MessageBox.Show(string.Format("Error copying DLL: {0}",exc.Message));
            }
        }
    }

Things that go download in the night....

2005-07-21T16:42:00.004-05:00

I was testing a secured website directory running on my local machine.

When accessing the resource as "http://www.mywebaddress.com" instead of "http://localhost". The Windows Integrated Authentication login popup would appear three times. I would type in the correct user name and password. But every time, I would be denied access. Eventually receiving the message:

HTTP 401.1 - Unauthorized: Logon Failed

I had a related problem while using Windows Server 2003 SP1.

Error while trying to run project: Unable to start debugging on the web server. You do not have permissions to debug the server.



Verify that you are a member of the 'Debugger Users' group on the server.

NOTE: I AM the administrator on this machine, and have made sure that I had the 'Debugger Users' role..

After much digging around I finally found, the crux of the problem is a recent security patch that came down with XP SP2 and W2K3 SP1. It is called loopback security check, and you can get around it by following the instructions in the Microsoft Knowledgebase.

An Embedded DB for the .Net Masses!

2005-04-01T16:28:00.002-06:00

I am so excited! I feel like Goldilocks after I have tried the porridge that is too hot, and the one that is too cold. This one is JUST RIGHT!

For those of you who have perhaps assumed that I have a screw loose somewhere, let me explain. Programming is fun, programming is cool, programming may even get you chicks... But one of the first fnagling problems facing a developer at the beginning of any project is, "how am I going to store the data?".

In many projects this may become immediately obvious either because of existing data, or available database systems. But this becomes more of a problem when talking about a thick-client, deployment from scratch. Now you are talking about a totally isolated machine, that you won't get much time (if any) to go around, visit and make sure everything is honkey-dorey. You are also talking about an installation that needs to be small (maybe you are deploying from the web), simple (there ain't no IT guys where this program is goin'), and secure (no good having a password on your application if everyone and their brother can simply look inside the file).

In this case the choices for embedded database become fairly few and far between. Let us add an entire Microsoft bias here and say that you only care about Windows™ development in .Net (se moi). Some of your choices might be: Access/Jet, MSDE (mentioned below), SQL Server Express 2005 , XML files, MySQL, Paradox (!?)

Well, how about VistaDB? Let's do a comparison:

Name	Requirements	Features	Drawbacks	Price
VistaDB	.Net Framework 1.1 (Mono?) 500K Redist	Encryption Transactions Triggers/Constraints Referential Integrity Indexing AutoIncrement Identities Multi-User Copy To Install		$129
Access/JET	<> (JET engine deprecated from MDAC and no longer available) 20MB	Included in older MDAC's Referential Integrity Indexing AutoIncrement Identities	Not always available	Going forward, each deployment will require an Access license.
MSDE	Windows 98 and above 70MB	Transactions Replication Multi-User 16 Instances Stored Procs/Views Triggers/Constraints Referential Integrity Indexing AutoIncrement Identities	Large Difficult Install Patches? Lockdown Needed	Free (with various Microsoft products)
SQL Server Express 2005	.Net Framework 2.0 (ONLY) 125MB Ram (after boot) ~40MB	Transactions Replication Multi-User 16 Instances Stored Procs/Views Triggers/Constraints Referential Integrity Indexing AutoIncrement Identities	Large Difficult Install Patches?Lockdown Needed	Free (with various Microsoft products)?
XML Files	You need to code libraries		Bulky Slow Lots of Custom Development Needed	Free
MySQL	~30MB	Transactions Replication Multi-User Indexing AutoIncrement Identities	Large Requires Installation Lockdown Needed	Free
Paradox	~10MB	Indexing AutoIncrement Identities	Prone To Corruption Old Technology Requires BDE install	Free (With various Borland tools)

On top of this, there is a very nice third party review of VistaDB by Mike Gundelroy. After looking at this list, there is no comparison if you want a small, fast, simple install for an application that includes a database. I'm sold! And, I just bought my copy to play with. I'll let you know if I have any complaints.

It is not just .Net you can obfuscate...

2004-06-07T18:09:00.002-05:00

It is amazing how panicked some customers will get when you tell them that their new application will have code on the client-side of a browser (using tiny words, so they understand the implications of that).

We are just rolling off of a 6 month development project for "savings calculators", to be used by the sales staff. The functional requirements forced some calculations to be performed on the client-side. Now the customer is upset that their business rules are exposed as JavaScript, "some competitor could steal our logic..." Believe me, I saw that logic, there is nothing there to steal!

Anyway, we were able to assuage some of their fears by using a little mentioned feature for applications using the Microsoft Scripting Runtime 5.0 or better. The Microsoft Script Encoder seems to be a nice way of obfuscating (though not encrypting JavaScript) that you need to send to the client. Not good for passwords or anything. But, fairly effective at deterring theft or modification of script.

Microsoft Script Encoder can be downloaded here.

The interesting thing is that this utility is simply a wrapper around the Scripting.Encoder COM object which can be invoked directly (See the attached link in this post). Which is good if you are spitting out dynamic script fragments from ASP or ASP.Net code.

A Little Background First

2004-06-03T19:04:00.002-05:00

Eh'm, let me introduce myself (by way of a long rambling tirade). For those poor unfortunates that have happened upon this dreary backwater of an internet blog, my name is Tom. I am a software developer in a very large company that doesn't have real developers. Compared to me, the Dodo is going through a veritable population explosion.

My department, and the 3 developers in it are the only official developers not associated with the public website in a company of over 15,000 employees. Oh, and they are in a separate division because they couldn't deal with the mainstream corporate IT hacks. Sure, there are a few people scattered throughout the rest of the organization, who call themselves developers. But, that is because they know how to use FrontPage, HomeSite, or Access. They wouldn't recognize a language if it jumped up and bit them in the ass.

We constantly have to go through variance processes in order to obtain required software, or machines. Since the company doesn't have any other developers outside of the public website, IT doesn't even know where to begin to deal with us, our development servers, and the various production servers and databases we manipulate. They know how to cookie-cutter off-the-shelf applications and put them on servers. But, are baffled by our request to be able to acces our own servers.

We have finally gotten them to realize that just because a server has power and is operating, it doesn't count as server uptime unless our application is actually able to run!

Hello World!

2004-05-19T13:12:00.002-05:00

In programming, the first application you learn to write in any new language is usually a "Hello World" app. It illustrates the basics of how to get the computer to say hello with the syntax for the language.

Well, this is my Blogger "Hello World". I will come back with more erudite pearls of wisdom, opinions, bitches, rants and general musings in the future.