This can be easily achieved:

• Go to the Connection properties of your dataContext
• Set the Connection string to None
• Set Application Setting to False

This will prevent the generator to create a default constructor. This makes it possible to add your own, which will read the connection string from the config file.

public YourDataContext()
   : base(ConfigurationManager.ConnectionStrings["connString"].ConnectionString, mappingSource)
{
}

Thanks go to David Klein

The name says it all, but I must emphasize there really is a lot of added value. I already work with CodeRush and Refactor Pro, so usually I’m not interested in all those new pluggins/tools.

This free tool from Microsoft has some cool new features, of which my favorites are:
- Solution Navigator (nice!)
- decent tab management
- CTRL + Click to go to definition

Check them out!

How to get the windows uptime

in short: execute the command net stats srv

I have a collection of strings:

List<string> someStrings = new List<string>() { "aaaaaaa", "bbb", "ccc", "dddddddd" };

And I want to remove the shorter items (with length < 4), so there should remain two items left.

My first (and amateuristic) attempt was this:

foreach (string s in someStrings)
{
   if (s.Length < 4)
      someStrings.Remove(s);
}

I always use the foreach loop, but it can’t be used when modifying the collection. (You CAN modify properties of the items in the loop, but not the item reference itself!).
When you do try, you’ll get the “InvalidOperationException: Collection was modified; enumeration operation may not execute.”

Somewhere in my gray mass, I reminded to use the for-loop. My second (and dangerous) attempt was this:

for (int i = 0; i < someStrings.Count; i++)
{
   if (someStrings[i].Length < 4)
      someStrings.RemoveAt(i);
}

No exceptions were thrown, but the outcome is not what you’d expect!! Due to the fact that someStrings.Count and i are out of sync, the item “ccc” is skipped.

So, here’s the correct code:

for (int i = someStrings.Count - 1; i >= 0; i--)
{
    if(someStrings[i].Length < 4)
        someStrings.RemoveAt(i);
}

Conclusion: use the for-loop and iterate backwards! :p

It’s a simple but invaluable tool to watch what happens behind the scenes with linq to sql.
It’s a realtime visual debugger, and gives immediate feedback about the sql statements and their performance.

In linq to sql, you must always profile your stuff, and check what the consequences are of your code modifications.
For instance, using compiled queries everywhere doesn’t always increase performance.

Check it out!

Note: if you’re using the MS Sql Profiler, turn on these two events:
T-SQL: Sql-StmtCompleted
Stored Procedures: RPC:Completed

One could argue if you should even use Detach() in the first place.
Here’s a nice discussion between Rick Strahl and Ian Cooper, where the latter suggests you should be sending messages across boundaries, not objects.
Steve Michelotti suggests to exclude reference data from your context.
I agree with the fact that you should be aware of what is contained in the dataContext. It’s not a garbage can, keep it small. The datacontext represents a unit of work.
However, I think this is not a complete solution. It’s not transparant, and doesn’t work every time.

In my search for a generic Detach() method, I came across this post of Jonas Stawski. It’s a generic solution with excellent performance.

You only have to add this base class method:

public void Detach()
{
   GetType().GetMethod("Initialize", BindingFlags.Instance | BindingFlags.NonPublic).Invoke(this, null);
}

The method uses reflection to call the Initialize() method, which will reset all the assocation properties. It can now be added to another dataContext, which will not try to save the assocation properties.

Jonas comes with a huge warning that the OnCreated() method is called after Initialize(), which could lead to unwanted behavior. I fixed this problem modifying the T4 template from which the entities are generated.

Normally, the Initialize() method is only included if you have turned on serialization. (By setting the Serialization Mode to Unidirectional). I modified the template so that it always generates these Initialize() methods.

#region Construction
public <#=class1.Name#>()
{
	Initialize();

<# if (class1.HasPrimaryKey) {#>
	OnCreated();
<# } #>
}

private void Initialize()
{
<# 		  foreach(Association association in class1.Associations) { #>
	<#=association.Storage#> = <#
	if (association.IsMany) {
		#>new EntitySet<<#=association.Type.Name#>>(attach_<#=association.Member#>, detach_<#=association.Member#>);
<#			} else {
		#>default(EntityRef<<#=association.Type.Name#>>);
<#			}
}
#>
}
#endregion

And I moved the call to OnCreated() to the constructor. Now, the code behaves exactly the same, and I’m able to call Detach() without any side effects! Nice….

Btw, here’s a free T4 editor if you need one.

I’ve seen other solutions that involved copying the entity properties using reflection or using serialization.
They’re simply a lot slower. In my test, they both took around 60 ms. This Detach() method takes 0 ms! :p

Download my custom T4 template, which is based on this Codeplex project. You have to rename the file to Model.tt.

At some point, intellisense was working strange. I didn’t give it much attention at the time. But after a while it really started to annoy me.
At first, I thought it was some kind of new feature of CodeRush. But it turns out to Visual Studio 2010 has different modes for intellisense.

The new Suggestion mode has lower impact. This mode was added to make intelliSense completion less aggressive in certain cases, most notably test-driven development scenarios. While in this mode, intelliSense will still show a completion list but will also show what you’re typing in a box at the top of the completion list. It will not auto-complete unless you explicitly select an entry in the list.

And you toggle between these modes with Ctrl + Alt + Space. Ah! ……

See it in action

Anyway, the value in this column is being used to check if the row has been changed after it has been fetched.
However, the timestamp column is deprecated and we should use the rowversion column whenever possible.

The thing that really confused me was that this type is not available in the designer. So when you add a column with the version type, you must do it in script like this:

CREATE TABLE Test (Id int PRIMARY KEY, Version rowversion);

I really don’t understand why it’s not there, but its pretty annoying. I created a script, and added the rowversion column. But after running the script, I had to manually add the FK’s again. Grrr…

I found this stuff after searching for performance optimizations for Linq to Sql.
Normally, a query would check for concurrency violations using all the columns. With the rowversion column in place, only a single column is checked, which is a lot faster.

When you’ve added the rowversion column, and update the dbml, the following output has been generated automatically:

So you don’t have to worry setting these properties manually.

I wanted to show properties on multiple lines (in a multibinding):

'

    
        
            
                
                    
                    
                
            
        
    

This results in the following tooltip (where the mouse hovers on the text “FTP”):

Here’s a simple scenario. I have a timer that elapses every second, and I want to check if it is equal to a specified DateTime variable (which has an accuracy of seconds).

The first thing that probably pops in your mind is this:

if(DateTime.Now == specifiedDate)

But the chances of that working are very slim. Under the hood, a comparison is made where the milliseconds are taken into account.

No biggie. I just create an extension method that trims the milliseconds (and preserves the Kind property)

public static DateTime TrimMilliSeconds(this DateTime dateTime)
{
    return new DateTime(dateTime.Ticks - (dateTime.Ticks % TimeSpan.TicksPerSecond), dateTime.Kind);
}

So now I have this comparison, which will leave out the milliseconds:

if(DateTime.Now.TrimMilliSeconds() == specifiedDate)

This will work most of the time. Not always? …… no not always.

The reason is that the timer doesn’t elapse precisely every second. It might take 1005 milliseconds to the next interval.
So in a worst case scenario you can have a check at 11:59:59.999, while the next interval will occur at 12:00:01:001. The 12:00:00 is “skipped”!

Now I check the difference, and allow a small margin of 100 milliseconds.

TimeSpan precision = TimeSpan.FromMilliSeconds(1100);
bool areEqual = (x-y).Duration() < precision;

I hope I saved you some headaches over this.