xml serialization in .Net with datetime

by Deepak Dhakal 8. December 2011 11:22

If you have

<xs:element name="start" type="xs:date"/>

make sure you parse as



or if you have

<xs:element name="startdate" type="xs:dateTime"/>


you parse as



if you don't then you will get error like

at System.DateTimeParse.ParseExactMultiple(String s, String[ formats, DateTimeFormatInfo dtfi, DateTimeStyles style)
at System.DateTime.ParseExact(String s, String[ formats, IFormatProvider provider, DateTimeStyles style)
at System.Data.SQLite.SQLiteConvert.ToDateTime(String dateText)
at System.Data.SQLite.SQLiteConvert.ToDateTime(IntPtr ptr, Int32 len)
at System.Data.SQLite.SQLite3.GetDateTime(SQLiteStatement stmt, Int32 index)
at System.Data.SQLite.SQLite3.GetValue(SQLiteStatement stmt, Int32 index, SQLiteType typ)
at System.Data.SQLite.SQLiteDataReader.GetValue(Int32 i)
at System.Data.SQLite.SQLiteDataReader.GetValues(Object[ values)
at System.Data.ProviderBase.DataReaderContainer.CommonLanguageSubsetDataReader.GetValues(Object[ values)
at System.Data.ProviderBase.SchemaMapping.LoadDataRow()br /> at System.Data.Common.DataAdapter.FillLoadDataRow(SchemaMapping mapping)
at System.Data.Common.DataAdapter.FillFromReader(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 startRecord, Int32 maxRecords, DataColumn parentChapterColumn, Object parentChapterValue)
at System.Data.Common.DataAdapter.Fill(DataTable[ dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[ datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable[ dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
at WindowsFormsApplication2.AssetManagerDBDataSetTableAdapters.AssetsTableAdapter.Fill(AssetsDataTable dataTable) in C:\Users\Administrator\Desktop\SQLite Version\WiscoAssetImporter\AssetManagerDBDataSet1.Designer.cs:line 4408
at WindowsFormsApplication2.FormMerge.FormAnalyse_Load(Object sender, EventArgs e) in C:\Users\Administrator\Desktop\SQLite Version\WiscoAssetImporter\FormMerge.cs:line 71


Add Archos on your Device list in Eclipse for Android Development

by Deepak Dhakal 1. October 2011 19:22

Archos support proposes a solution to the bug on ADB connection mode with Mac OSX 10.6.2 with firmwares updates since 1.4.07 to the latest 1.4.16 :

You actually need to modify or create the adb_usb.ini file

In terminal, you need to type :
echo "0x0e79" >~/.android/adb_usb.ini
./adb kill-server
./adb start-server

I just modify the first command in order to preserve the original contents of the ~/.android/adb_usb.ini file by issuing the following command
echo "0x0e79" >> ~/.android/adb_usb.ini

Here is the result :

$ adb devices
List of devices attached

$ adb devices
List of devices attached

$ more ~/.android/adb_usb.ini
# USE 'android update adb' TO GENERATE.
$ echo "0x0e79" >> ~/.android/adb_usb.ini
$ more ~/.android/adb_usb.ini
# USE 'android update adb' TO GENERATE.
$ adb kill-server
$ adb start-server
$ adb devices
List of devices attached
A5S-xxxx0004-xxxx0000-0403xxxx-1500xxxx device


Is there any tool that converts Objective C code to java for Android

by Deepak Dhakal 9. February 2011 13:42

I have a working iPhone app and want to convert to Android app with minimal effort. Can anyone suggest ?


I don't think so. You're best bet would have been to develop the application from scratch using a platform like Appcelerator or Phone Gap.

The commenter makes an excellent point: the platforms are fundamentally different. A straight conversion of code won't work. You also have to convert framework/api calls and restructure all of your UI. Not only is the framework different, but the assumptions made by the platform are totally different as well.

Possibly the best way to reuse the most code (this isn't necessarily the easiest, keep in mind) would be to convert as much objective c code into C or C++ and make use of the Android NDK. You won't be able to reuse any of the UI code, but you might be able to reuse a significant amount of your application logic depending on what your application does.


.Net | iPhone

C++ Code, Is your code Messy ?

by Deepak Dhakal 14. December 2010 08:32

I’m pretty sure that every programmer would agree that good code is difficult to write. I think though that the C++ language makes this abundantly clear.

C++ is a compiled language frequently used for GUI applications and for games. It has a high barrier to entry due to the complexity of the language. However, this complexity is also what proves that good code is difficult to write. For example, the use of the ‘const’ keyword can be used to indicate that a member function does not change the class. It can mean that a parameter cannot be modified within a function. It can mean that a return value cannot be modified. And the list goes on. Remembering all these details and making sure they are applied correctly is very difficult.

Added to this, there are ways to take shortcuts that can have very detrimental effects down the road. For example if you take a shortcut with the use of ‘const’ you will most likely get a very confusing compiler message that could be very difficult to figure out.

Here at Worthwhile we mostly use interpreted languages. This means that translation of the source code to machine code happens when the program is run. C++ is a compiled language which means that a programmer must use a tool to generate the machine code before the program can be run. Interpreted languages in general are more flexible than compiled languages and make it less difficult to get the details right. However, if the programmer is not thinking about all of the possible ways his code might be used he will undoubtedly get burned later.

For example, consider a function that retrieves data from a database. The function accepts parameters that are used to filter the results down to what the user wants to see. The simplest way to do this is to use string concatenation. So if I am looking for people with the name of ‘Fred’ the query would look like: “SELECT * FROM people WHERE name = ‘Fred’”. If Fred is stored in a variable, the line would look like this in PHP: “SELECT * FROM people WHERE name = ’”. $variable .’”. So what is wrong with that? What if the variable that contains “Fred” is changed to contain “Fred; DELETE * FROM people;”? Well now you could have just inadvertently allowed the user to delete all the data you were trying to keep in the table. This is an example of a SQL injection attack technique.

Good code requires lots of thought. C++ makes you consider additional aspects of how code could be used. Scripting languages do not require that you do that. Lazy or partially thought out coding practices can lead to major security flaws! Have you ever been bitten by poorly written code?


ASP.NET Performance ( Web application )

by Deepak Dhakal 20. April 2010 11:41


In the IT world, software applications are being rapidly developed. Clients, and so employers, are just looking for those teams/individuals who can build up applications rapidly, just bothering to make their application live; but what often happens after an application goes live is that users start to use the application and it doesn’t respond well. At this point, clients start to lose users and business.

To code an application is not a big deal; I believe it can be done by virtually anyone, meaning it is not necessary to have great knowledge or experience. Improving performance of an existing application (especially an one put together rapidly) could be quite risky and could cause many ripple effects. Things must be planned first to avoid horrible results.

The following are a few points that can make a site scalable and reliable; but which may initially slow down development. I believe that overall, when maintenance and future changes are taken into account, total development time would be reduced.

1. Minimize HTTP based Requestss

Problem 1: Serving images - no matter if they are of less than 1 KB - as separate web resources, cause separate web requests to the server, which impact performance.


  • Use Image Maps to merge up images, though image Maps could only merge up those images which are in sequence, like navigation images, so it depends upon your web site/page design.
  • Use Inline images. Inline images could increase your HTML page size but would cause fewer requests to the server.
  • CSS Sprites can also be used to merge up images and setting their position and backgrounds.

Problem 2: Using CSS is very good practice but serving stylesheets as separate resources, thus causing separate requests, should be considered very carefully.


  • Try your best to combine all your CSS based classes into a single .css file as lot of .css files will cause a large amount of requests, regardless of the file sizes.
  • .css files are normally cached by browsers, so a single and heavy .css file doesn’t cause a long wait on each page request.
  • Inline .css classes could make HTML heavy, so again: go ahead with a single.css file.

Problem 3: JavaScript is an awesome scripting language which can be quite powerful to play with. Nonetheless, it should be used carefully not only for request size issues; but also because it can have a way of causing unpredictable performance issues.

Solution: Inline JavaScript could make the HTML page heavy, so it’s preferred to serve separate .js files or a single JavaScript file to keep all JavaScript-based scripts in a single place.

JavaScript files also get cached automatically by browsers, so they usually aren’t requested each time the page is loaded by the browsers.

2. HTTP Compression

HTTP Compression is used to compress contents from the web server. HTTP requests and responses could be compressed, which can result in great performance gains. Through HTTP compression, the size of the payload can be reduced by about 50%, which is great. Isn’t it?

HTTP Compression is now widely supported by browsers and web servers.

If HTTP compression is enabled on the web server, and if the request header includes an Accept-Encoding: gzip, deflate header, the browser supports gzip and deflate compression mechanisms, so the response can be compressed in any of the given formats by the web server in order to reduce the payload size. This leads to an increase in performance. Latter that compressed response is decompressed by the browser and rendered normally.

Following are very good links which detail HTTP Compression and their implementations:

  • Click here to get detailed knowledge on HTTP compression.
  • Click here to learn how to enable HTTP compression in IIS.

3. Correct Formatted Images at the Right Place

Problem: Normally designers use JPG or GIF formats quite randomly and ignore some other good formats to compress images.

Solution: Correct format should be used for right purpose like

  • If you have to place a background image, some large image or a screenshot then the suggested format is JPG/JPEG.
  • If you have to use small graphics like button images, header images, footer images, navigation bar images or clip arts, then the suggested format is PNG.
  • If an image is not required to be in high or true colors and 256 colors are enough, then GIF is preferred.

4. Compress CSS, JavaScript and Images

CSS files (.css), images and JavaScript (.js) files can be compressed, as normally .css and .js files contain unnecessary spaces, comments, unnecessary code and such other things. A number of high quality (and free) utilities are available to help you pre-compress your files.

Following are a few good links for such utilities:

  • Compress PNG images by clicking here
  • Compress JPG images by clicking here
  • Compress .CSS files by clicking here and here and here
  • Compress .Js files by clicking here and here and here

I have used these utilities and seen compression results of about 50% in file size reduction after using such loss-less compression, so I recommend them.

5. CSS at Top

The recommended approach is to put CSS links on top of the web page, as it makes the page render progressively efficient. Since users want to see the contents of a page whilst it’s loading rather than white spaces, contents/formats should be given on top. HTML Specifications clearly say to declare style sheets in the head section of a web page.

6. Javascript at Bottom

When scripts are defined on top of the page they can take unnecessary time to load; they don’t show the contents that users are expecting after making any request to an HTTP web server. It's better to display a the HTML contents of a page, then load any scripting code (when possible, of course).

Preferably use/link up JavaScript-based scripts at the bottom of a web page. Alternatively you can use the defer attribute, which runs the script at the end of page loading, but that is not the preferable approach as it is not browser independent. For example, Firefox doesn’t support it and could mess up with document.write, so only use it once you fully understand the implications.

7. Content Delivery Network: (CDN)

When a browser makes a request to any web page – that is, he types a URL/URI of any web page or web site, a request goes through many hops (routers and computers) and then finally reaches its final destination. This happens both for requests and responses. This operation affects performance and can severely effect load time.

A Content Delivery Network implies a collection of computers, distributed all over the world, which deliver data (contents). Through a CDN you can have your website data on multiple servers distributed in different locations around the world. Distribute web application data in different places around the world so request can be served from the nearest location and save time (which means performance and money as well).

8. Ajax

Problemm: Ajax is being increasingly used to improve usability, but oftentimes in a way which increases overall server load.


Preferably use the GET method for Ajax based Requests, because if you use POST method then the request header would be sent first, followed by the data, which basically splits the request in two steps. A single-step request can be achieved with GET if a cookie is not too long and the URL is not larger than 2k.

  • When using ASP.NET AJAX and the UpdatePanel control for partial page rendering, use the maximum number of update panels to update small chunks of page, but use them wisely. Don’t set the Update property to Always unless needed. Instead, set the update mode to Conditional, otherwise all the partial chunks would be sent together after each asynchronous postback.
  • Ajax based requests can also be cached when using the GET method. If the URL is the same, then cached data can be used from the client, and a round trip to the server can be avoided.

9. Ajax vs. Callback

Problem: Ajax is a great solution for asynchronous communication between client (web browser) and HTTP servers, but one solution can't be applied to every problem. This means that Ajax is great mechanism for sending requests to the server without making a full page postback, but what if you need to send a request to the server and don’t even need partial rendering?

Solution: best solution is Callback.

For example, if you need to check whether a user exists or not, or if a user has forgotten his/her password and you just need to send a request to the server to check if user name exist, there is no need for client-side render - just a server side operation.

Following are a couple of great links which explain callbacks: Please click here and here.

10. Reduce Cookie size

Cookies are stored on the client side to keep information about users (authentication and personalization). Since HTTP is a stateless protocol, cookies are common in web development to maintain information and state. Cookies are sent with every HTTP requests, so try to keep them low in size to minimize effects on the HTTP response.

Cookie’s size should be minimized as much as possible.

Cookies shouldn’t contain secret information. If really needed, that information should be either encrypted or encoded.

Try to minimize the number of cookies by removing unnecessary cookies.

Cookies should expire as soon as they become useless for an application.

11. Use Cache appropriately

Cache mechanism is a great way to save server round trips - and also database server round trips - as both round trips are expensive processes. By caching data we can avoid hitting them when unnecessary. Following are few guidelines for implementing caching::

  • Static contents should be cached, like “Contact us” and “About us” pages, and such other pages which contain static information.
  • If a page is not fully static, it contains some dynamic information. Such pages can leverage the ASP.NET technology, which supports partial page caching.
  • If data is dynamically accessed and used in web pages - like data being accessed from some file or database - and even if data is consistently or regularly changed, then that data could be cached by using ASP.NET 2.0 cache dependency features. As soon as data changes from the back-end by some other means, the cache would be updated.

Now that web technologies such ASP.NET have matured and offer such great caching capabilities, there's really no reason not to make extensive use of them.

Following are few very good links to implement caching for different types of data (static and dynamic):

  • Click here to cache Full page (static page caching).
  • Click here and here to cache partial page caching.
  • Click here to cache dynamic data with dependency.

12. Upload compiled code rather than source code

Pre-compiled ASP.NET pages perform much better than source code versions. Actually pre-compilation give web sites a performance boost especially when the first request is made to a folder containing that resource.

Uploading a pre-compiled version boosts up performance since the server doesn’t need to compile a page at request-time.

13. Conclusions

Following are few good practices to gain better performance::

  • For HTTP compression, GZip is considered the most effective and most popular by means of browsers and HTTP server. It can reduce file size up to 70% in size.
  • Always keep JavaScript and CSS in external files.
  • Avoid redirects until needed. Server.Transfer is also provided so consider that as well since it performs better in some conditions.
  • Minimize use of Iframes as it's costly.
  • Avoid try-catch blocks for control-flow as they perform poorly. Exceptions should be used only in truly exceptional situations.
  • Minimize Cookie/CSS sizes.
  • Minimize DOM objects on page as they are heavy weight.
  • Use link tags rather than @import to use/link up CSS.
  • Favicon, being a static image displayed in the browser’s address bar, should be cacheable and compressed.
  • Always prefer a cache-friendly folder structure. For example, create specific folders for static contents, like /static for static images/static pages…
  • SSL can never be cached so minimize its usage. Keep it for those pages which need to be secure, rather than using it for all the pages.
  • HTTP Post requests can’t be cached, so choose the HTTP method appropriately.
  • Prevent Denial of Service (Dos) attacks. Recommended article here.
  • Prevent SQL Injection. Recommended article here.
  • Prevent Cross Site Scripting (XSS). Recommended article here.

I hope you have learned some very good approaches and techniques to keep your web application in good shape on an HTTP server. I personally don’t think any are flat-out ignorable nor is any too difficult to implement.

As performance is a vital part of success for any web application, I have tried to be as general as possible, so every web technology (ASP.NET, asp, php, jsp, jsf and so on) can follow these tips.



VSTO Add-In installation woes

by Deepak Dhakal 11. December 2009 11:28

Update, Oct 12, 2009: if you are looking for a way to install a VSTO add-in with multiple dll, I found out there was a better solution here.

I just completed my first real-life VSTO project, and I am officially a convert: I can do everything I did in VBA, using mature languages like C#, and the comfort of the Visual Studio development tools.

Everything has not been smooth, though. I struggled quite a bit initially with deployment, a problem which just does not exist with VBA. However, after some digging, I came across this great post, which provides comprehensive step-by-step guidelines on setting up an add-in project for Office 2003.

At that point, I thought my issues were over, and I just cruised along, happily coding in C#. And then I decided that I would extract the logic of my calculation engine in a separate dll, which I would reference in my Excel add-in as a “satellite assembly” – and had a bad surprise. On my development machine, everything worked beautifully, and when I ran the installer on a clean machine, it installed my add-in without any complaint (The satellite dll was even added to the add-in folder), but somehow, the add-in did not run. No error message, no indication of a problem, but where I expected my dll to perform calculations, nothing happened.

Before getting into how I resolved the problem, a quick word on why I thought this would be a good idea to separate the business logic in its own dll. I had two motivations to do that: reuse, and testability.

There is nothing wrong per se in keeping all your code in the add-in project. However, imagine you build a calculation engine which could be re-used in other projects. If all your code is in the add-in project, you would have to copy/paste the code file into the other project, and to painfully change namespace and references all over the place, to integrate it in the new project. This is very unpleasant – and you will have to do it every time you create a new project. On top of this, if you end up finding a bug in your code (this happens, even to the best of us), you will have to manually change the code in all projects. By contrast, if your business logic is nicely separated in a dll, the only thing you need to do is to reference that dll in any project that uses it, and you are done; and if you find a bug, you need to fix it in one place only, and re-reference the updated dll, and you are done. No code duplication, minimal manual work: much better.

The other issue is testability. I am a unit-test fanatic, and like to build tests as I go, adding tests hand in hand with code, and leveraging the refactoring tools of Visual Studio. I also like to separate the tests from the project itself, so that I don’t have to ship my tests with my product. To do that, I typically add a second project to the solution, which contains only unit tests, and references the main project. The problem here is that because of the technology behind VSTO projects, you cannot reference the VSTO project in your unit test project. You have to do one of two things: referencing the add-in dll, or building the tests in your main project, i.e. shipping them included with your product. And if you reference the dll, you lose all Visual Studio refactoring support, and your whole test-driven development cycle becomes very painful. That’s not good.

So what can you do about it? It took me some time to figure it out, but the solution is actually relatively easy. The post mentioned earlier has a small-print caveat:

This article makes the following assumptions about the project that you will deploy:
•    There is only one customization assembly; there are no other referenced or satellite assemblies deployed with the solution.

The issue is that in order for your add-in to work with your “satellite assembly”, i.e. your dll, you need to explicitly grant security trust to that dll as well. How do you go about that?
The procedure is fairly simple, and follows the same general lines described to grant security to the add-in assembly. I assume that you already have set your project up so that you have the add-in project, the SetSecurity project, and your add-in deployment project in place.

I assume also that you have referenced a dll in your add-in project – in my case, the AddInEngine dll.

Right-click on the deployment project (in my case, ExcelAddInDemoSetup), and select View > Custom Actions. If you followed the guidelines provided by the post I reference, you should see 4 “folders” Install, Commit, Rollback and Uninstall, each of them containing one item “Primary output from SetSecurity (Active)”.

Right-click “Custom Actions” > Add Custom Action, and select “Application Folder” in the combo box; Click “Add Output”, “SetSecurity” and “Primary Output”. At that point, you should see that each of the 4 folders now contains 2  “Primary output from SetSecurity (Active)”. I recommend that you rename the ones that have just been added to something like “Primary output from SetSecurity for AddInEngine (Active)”, so that you know what's what.

The procedure now is identical to the one you followed to grant security to the add-in dll itself. The CustomActionData field for the original Custom Action granting security to the add-in dll looked like this:

/assemblyName="ExcelAddInDemo.dll" /targetDir="[TARGETDIR]\" /solutionCodeGroupName="MyCompany.ExcelAddInDemo" /solutionCodeGroupDescription="Code group for ExcelAddInDemo" /assemblyCodeGroupName="ExcelAddInDemo" /assemblyCodeGroupDescription="Code group for ExcelAddInDemo" /allUsers=[ALLUSERS]

In the Custom action you just added, simply replace “ExcelAddInDemo.dll” by the name of your satellite assembly, so that your CustomActionData field looks something like:

/assemblyName="AddInEngine.dll" /targetDir="[TARGETDIR]\" /solutionCodeGroupName=" MyCompany.AddInEngine" /solutionCodeGroupDescription="Code group for AddInEngine" /assemblyCodeGroupName="AddInEngine" /assemblyCodeGroupDescription="Code group for AddInEngine" /allUsers=[ALLUSERS]

Do the same substitution in the Rollback and Uninstall; at that point, you should see something like this, and you are set to go!

If you have multiple dlls referenced, you will have to grant security to each of them individually, which is a bit tedious. Hopefully, I can find a way to automate that process down the road…



Src: http://www.clear-lines.com/blog/post/VSTO-Add-In-installation-woes.aspx



Powered by BlogEngine.NET - Old School Theme by n3o Web Designers