Tuesday, February 2, 2010

KML objects with .Net

Just finished translating the kml 2.2 beta schema into a .Net business object. Using the xsd tool only took me so far, i actually had to get rid 3 items for it to work at all:

atom:author
atom:link
xal:addressdetails

With that, i was able to to get a viable set of business objects representing the schema. Creating a kmlobject though and trying to serialize it didn't work, however, and I had to make a few more changes. Namely, I needed to add an XMLInclude for DocumentType and FolderType everywhere where an XMLInclude existed for NetworkLink. I've included the finished product here.

Labels: , ,

Sunday, March 8, 2009

The database is not initialized

I was having an irregular issue when working with a SqlCeReplication object in .Net, that i was often getting the error "The database is not initialized". My synchronization methodology was that the 'synchronize' method was called periodically to sync the client with the server. The problem turned out to be when the client would click on my synchroninzation window, which would tell the user when the last synchronization occured, and what changes made. I got this information from the 'LoadProperties' method in the SqlCeReplication object. The issue, apparently, is that if a synchronization is going on while i call LoadProperties, then i get the error.

Since the SqlCeReplication object does not tell you it's progress, that the object is synchronizing or cancelling or whatever, i needed to create a wrapper around the object to do it myself. Once i did this, the problem was gone.

The lack of some sort of 'status' indicator for the SqlCeReplication object is probably one of the biggest problems i see with using it, but there are ways around that.

Labels: ,

Thursday, February 19, 2009

ContextSwitchDeadlock was detected

I was recently getting the following error in my code:

ContextSwitchDeadlock was detected

Message: The CLR has been unable to transition from COM context 0x143728 to COM context 0x1435b8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.


which is also described here

This issue seemed to happen when I was trying to close a SQLCeConnection. I have a shared dataaccess layer that handles all of my SQL connectivity, where I open a connection, and close it immediately after the transaction has been completed (more on whether or not this is the best way of handling things with SQL CE later).

Looking into this issue gives basically 2 responses:
1) Turn off the MDA response in visual studio that gives this error
2) use STA pumping

Response 1) was worthless for me, because this issue was translating to the non-debugging clients as the application just freezing, so it wasn't just a debugging issue.

Response 2) sounded good, but i got a lot of conflicting and unhelpful information on how to do this. There's some vague information about using CoInitializeEx , but that didn't really help my situation, unfortunately.

So i started looking at the actual database call. Apparently, i had a WPF gridview with a datacontext set to a collection of a custom business object (let's call it 'customer'). This Customer business object had a readonly string property in it where it got it's value by checking the database. Apparently, it was this call that was causing the issue, and if I set this property instead at the objects instantiation (instead of calling it every time the property was looked at), the issue went away.

This was especially weird, because i recently upgraded this project from .Net 2.0 forms to WPF, without changing the business objects/data layers at all. The old 2.0 project worked fine with no issues at all with this configuration. Apparently WPF doesn't like it at all.

Labels: , , , ,

Tuesday, December 2, 2008

Response.End vs Response.Close

I was having an issue that took me a lot longer to pin down than it should have. I have an application that saves all of it's 'attachments' to a database on a server. If a user wants to see these attachments, they get sent to a 'viewattachment' web page, which, depending on the file, either allows the user to save it to their local machine, or displays it in the browser (like for an image).

For some reason, the larger files (the images) were basically freezing during the page load. When I would hit the stop button on the browser, part of the image would show, but leaving it to run would never really work. I finally found the issue, which was in 1 line:

Response.End();
Response.Flush();
Response.Close();

I don't know why I had the 'End' at that particular point, but putting it there meant that it would end the response before it had finished painting it on the browser. It basically just killed the page. Moving the 'End' so that it came after 'Close' fixed the issue.

Now I just need to find out if it's even necesary to call response.End if I'm already calling response.Close.

Labels: , , , ,

Sunday, November 2, 2008

Isolated storage is not FIPS compliant

I talked earlier about using Isolated storage in order to save a clients information in an encrypted format locally - things like passwords used to connect to a server, etc. The application that i've been brought to work on would previously save the password information as an encrypted string, in an unencrypted file. The unencrypted file was bad enough, but even if the string is encrypted, this offers no protection. Since the file isn't tied locally to the machine in any way, anyone could just copy the file to a different machine, and without even knowing what the password is, be able to access the server with no issues.

So enter Isolated storage, which I thought would have fixed this issue. The main problem, which i just found out yesterday, is that it isn't FIPS compliant, which is a big problem if your application is going to be run on government computers. I was testing our application on a machine with the group policy setting set to require FIPS compliance, and it came up with an error. Apparently the encryption that Isolated Storage uses is the Sha1Managed class. There isn't a whole lot of documentation that I could find on which classes are FIPS compliant, although I did find this helpful blog explaining an easy way to find out.

FIPS compliance has come up as an issue for me in the past. I've been disappointed that RijndaelManaged, which is the .Net version of AES, isn't FIPS compliant. This leaves the best encryption in .Net classes that I can use as TripleDES.

A good solution to replace Isolated Storage is to create your own encrypted file, encrypted using TripleDES. Using ManagementClass("Win32_Bios"), and getting it's SerialNumber value to use as the salt should work fairly well for most needs.

Labels: , , ,

Friday, October 17, 2008

ItemsControl and Virtualization

i was recently having an issue with an ItemsControl that would take up to 10 seconds to refresh with only 400 records inside it. The structure basically looked like:

<ItemsControl ItemsSource="{Binding Source={StaticResource dataLog}}" ItemTemplate="{StaticResource xamlLogSummaryTemplate}" VirtualizingStackPanel.IsVirtualizing="True">
<ItemsControl.ItemsPanel>
<ItemsPanelTemplate>
<StackPanel Orientation="Vertical" />
</ItemsPanelTemplate>
</ItemsControl.ItemsPanel>
</ItemsControl>

So I thought to speed it up, i would change the panel to a VirtualizingStackPanel. Didn't seem to help at all though. After trying several different options, I found that simply replacing the ItemsControl with a ListView made a tremendous difference. Basically, it seems like Virtualization doesn't work with ItemsControl.

Labels: , ,

Wednesday, October 1, 2008

UAC and event log writing

I have an application that writes errors to the eventlog of a clients machine, and I recently found that if the user has Vista installed and UAC is still on (which I can't imagine why people wouldn't turn it off, but you can't count on that), then you cannot write to the event log. Not only that, but

SecurityManager.IsGranted(New EventLogPermission(Permissions.PermissionState.Unrestricted))

will not give an accurate result back. Even with UAC turned on, this value will return back "TRUE", but then error out the instant i check:

EventLog.SourceExists

I get an error saying that I don't have the security privledges to do this. A window from the UAC doesn't even pop up for me to allow this either. If I turn UAC off, then this procedure works.

This does not perform how I would expect.

Labels: , , ,