One thing I always hated about developing for mobile devices is waiting for deployment. Hit <F5> in Visual Studio... and wait for all the assemblies being copied to the device.
A workaround for this can be, to setup the device emulator’s storage card to point to the bin folder. Doing this you have instant access to the updated binaries, whenever you build. In the emulator click File -> Configure. In Shared Folder add the path to your target library.

With this, you can execute your program instantly upon a new build without waiting for deployment. But if you want to debug your code you can try to attach to process, and get an error saying Unable to attach to the process. Attach is not enabled for this process with this debug type.

You’ll need to use Visual Studio’s remote tools Windows CE Remote Registry Editor to enable remote debugging. Add the following d-word to registry and set the value to 1:
HKLM -> Software -> Microsoft -> .NetCompactFramework -> Managed Debugger -> AttachEnabled

 
This enables debugging on the device, but be aware it slows down the device quite a bit, so it should only be done on development devices.
Doing it this way, you build and attach, no wait for deployment. It showed to be quite a time saver for me.

Note: In general it cannot be recommended to execute programs from the storage card, it can show to be quite unstable. But for debugging purposes it’s great.

• Biztalk taught me, not to put more than 65000 files in one folder
• Microsoft CRM taught me not to do more than 1024 joins in one select statement (if you're working with SQL 2005 and newer)
• Ibatis taught me not to use more than 2100 parameter in a sql command
• Some stupid code taught me not to select 50000 rows and store them in session

The other day, I had to convert some old reports from Report Server 2005 to be able to compile in Visual Studio 2008.

The first challenge about this was, that all the developers at the clients place runs VS 2008, but the SQL Server is 2005 - hence the developers only runs SQL 2005 on their dev machines. This results in VS not being able to recognize the report projects.

Solution for the first problem is, to install Business Intelligence Studio 2008 from the SQL Server 2008 installation. I ran the full installer, but only selected BI to be installed, and it does not seem to interfer with the actual SQL 2005 instance, that is running on the dev machine.

Second problem is, that these reports is using a custom assembly. The reports all referenced the custom assembly, but building the project failed - claiming it couldn't find the assembly. It appears, that the assembly has to be copied to a directory under Visual Studio, since reports sucks. The directory in my case was C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies. But the final solution to this would be, to add a post build event to the project copying the assembly to the correct directory: copy "$(TargetPath)" "$(DevEnvDir)PrivateAssemblies"

 So now it builds... everybody is happy... hehe ... heard that before :)

The reports still fails runtime on the server. The custom assembly needs to be deployed, in this case in the folder C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services\ReportServer\bin.

Note that the mentioned folders is pretty much different from versions of Visual Studio and SQL Server. The mentioned folders are pretty much standard for Visual Studio 2008, but is very much taken from my own installation, and may vary from setup to setup.

Update 20091125: Whatever team in MS who does the reporting services fucked up again. Even though you can compile the reports under 2008 and have them running on the production server, they will not work if you modify them in VS 2008 and try to deploy it on an SQL Server 2005. They changed the schema again, so it seems there's no way you can edit reports in VS 2008 and run it on SQL 2005 - you need to have VS 2005 installed.

Erik Ejlskov posted this great tip on how to format dates in sql scripts to avoid localization issues. {ts '2009-05-11 23:00:00'}

I started writing a small application, which can handle objects in Pocket Outlook Object Model (POOM) items, aka Appointments, Contacts etc.

Writing a simple LinQ query to select my appointments, with a specific subject:

IEnumerable<Appointment> filteredAppointments = from appointment in appointments

                    where appointment.Subject == "Cornelius 2001"

                    select appointment;

 I was astonished to find, that this gives a compilation error, with a description saying “Could not find an implementation of the query pattern for source type”. Since I previously did a lot of work with POOM, I’m not that surprised with the fact, that there are always surprises.

Search Google for 5 minutes gave the solution. Explicitly specify the type of the object you want to select:

IEnumerable<Appointment> filteredAppointments = from Appointment appointment in appointments

                    where appointment.Subject == "Cornelius 2001"

                    select appointment;

The last year or so, I’ve had a problem just about every time, I’ve restored a database that was backed up from another server.  After every restore, the applications I’ve been working with, throws an exception with authentications errors. The last project I worked on, we could solve this by deleting the user from the DB and add again.  A pretty weird solution, but it worked. But today I ran into the same problem, on another application, where I wasn’t able to delete the user for some reasons. So what to do? It would be nice to find the right solution to this topic, and not just the workaround I’ve been using previously.

The last few months I’ve had the pleasure of working with Erik Ejlskov, who knows a lot about MSSQL Server, so why not just ask him? As usual he was just about, to send a mail to everybody in the office with a solution to this.

If you get the failing authentication, after restoring a database, run the following sproc:

EXEC sp_change_users_login 'Update_One', '[username]', '[username]';

 I wonder what Update_One means, maybe Erik can give an answer to that tomorrow. Anyway it works, and I wish that I'd known this before, since it's really been bugging me.

Who can show the worst code ? Recently I ran into something like this:

        public string[] GetSomeVeryStupidArray()
        {   
            Dictionary<string, string> customers = GetCustomers();
            string[] list = new string[customers.Count];
           
            list[0] = customers[Constants.FirstConstant];
            list[1] = customers[Constants.SecondConstant];
            list[2] = customers[Constants.ThirdConstant];
           
            return list;
        }

        private Dictionary<string, string> GetCustomers()
        {
            string[] customers = new string[]
            {
                Constants.FirstConstant,
                Constants.SecondConstant,
                Constants.ThirdConstant
            };

            Dictionary<string, string> values = new Dictionary<string, string>();
           
            foreach (string name in customers)
            {
                values.Add(name, name);
            }

            return values;
        }

        internal class Constants
        {
            internal const string FirstConstant = "FirstConstant";
            internal const string SecondConstant = "SecondConstant";
            internal const string ThirdConstant = "ThirdConstant";
        }

Obviously I rewrote this a bit, so I don't offend the person who accually wrote it, but what the f*** is going on ??? I found code similiar to this, in accual production code. The worst part is, that I saw, that some other developer has been copy pasting these methods into new areas of the application we're working on, without even thinking about, what it is he's pasting.... Only two days left...

Working at Microsoft we had a checkin policy, that you can't checkin without associating the changeset with a work item. Never really occured to me, why we had to do this, but it seemed like a good practice.

 On the last two projects I worked on, that involved Team Foundation Server as version control, the customer has been using other software for bug tracking. Because of that, we haven't used workitems, and it seems like there's no point in associating changesets to workitems.

That was a wrong assumption. After I completed the first task on the project I'm currently working on I discovered, that it is a requirement that we create a document, describing every change that's been done to the code. The document is meant for code review, so it's a fairly good idea. But - when I had to track down every change done in the repository for 14 days of work, and 20 other developers made checkins, it showed to be a bit of a task to track down my changes (and boring as well).

On the next task, we decided to create a workitem. Not that it'll be used by anybody else. But we decided to create it, and agreed to associate every checkin with the workitem, so that it'll be a piece of cake to list the changesets regarding this task.

Now this seems like a pretty good solution to me. This way we can always track down every change done, regarding this task. But is it without problems? I don't think so. First of all, it requires some discipline from the developers to do the association. I've seen too many developers who doesn't even bother to write a comment, when they checkin. Another problem on the current project is, that there hasn't been awareness of the details in the code review document, until everybody completed a task which typically lasted 2-4 weeks. So what can you do, when it's too late ?

The best solution I found so far, to track down your own changes is to install the "Team Foundation Server Power Tools" which can be found here: TFS powertools .

You'll get lots of small extra stuff in you're team explorer. One thing is, that you'll get a node in the treeview displaying your team members. On the team members node you can get a list of every changeset that's been done by a specific developer, hence help you do the code review.

Big brother? Maybe, but very helpfull.

Update 20090424: Erik Ejlskov told me about a tool for doing extended searches in the repository called "Team Foundation Sidekicks". Pretty cool 3rd party tool, can be downloaded here: Team Foundation Sidekicks