For later reference:
–jeroen
Archive for March, 2011
How can I generate a consistent but unique value that can coexist with GUIDs? – The Old New Thing – Site Home – MSDN Blogs
Posted by jpluimers on 2011/03/25
Posted in Development, Software Development | Leave a Comment »
Some LinkedIn sender addresses you can use for filtering
Posted by jpluimers on 2011/03/25
Years ago, I set some filters on incoming messages from LinkedIn. Boy I was wrong: the filters were way to generic, resulting in too much mail skipping my inbox.
Here is a run-down from LinkedIn sender addresses I got mail from over the past couple of years:
- answers@linkedin.com – the Q&A part of LinkedIn
- communication@linkedin.com – some generic overview statistics reports ???
- connections@linkedin.com – connection confirmations
- connections_dev@linkedin.com – connection confirmations (seems not to be in use any more)
- emailconfirm@linkedin.com– confirmation of email address
- groups-noreply@linkedin.com – group announcements
- group-digests@linkedin.com – digest group messages
- groups@linkedin.com – individual group messages
- invitations@linkedin.com – incoming invitations
- member@linkedin.com – invitations / direct messages
- messages-noreply@linkedin.com – direct messages or CCs of messages
- requests-noreply@linkedin.com – group introductions
- updates@linkedin.com – sitewide updates, notification of email bounces
- linkedin@em.linkedin.com – ??? correlation unclear (only 10 msgs)
Have fun adjusting your mail filters!
–jeroen
Share this:
Posted in LinkedIn, Power User, SocialMedia | Leave a Comment »
trace switches for LLBLGenPro
Posted by jpluimers on 2011/03/24
I always forget which trace switches in the App.Config come in handy when using LLBLGenPro.
So I remember: The most important one is SqlServerDQE.
More of them are explained in Righthand blogs : Implementing more useful tracing for LLBLGenPro 2.0.
–jeroen
Share this:
Posted in .NET, Development, LLBLGen, Software Development | Leave a Comment »
SccProjectName value in .csproj hosed – strange build results (via: Interesting support case – Visual Studio solution prompts for entire SCC check-out on open – Developer Support Team Foundation Server – Site Home – MSDN Blogs)
Posted by jpluimers on 2011/03/24
Something in TFS screwed a SCC references in one of the .csproj files at a client.
As a result, it generated strange build errors (unfound projects in the wrong branch), because when loading project from the correct, the IDE in fact loads it from the wrong branch.
When you read the blog post from the Microsoft TFS development support team, the solution looks simple: in a regular project the values for SccProjectName, SccLocalPath, SccAuxPath and SccProvider should all be SAK (indicating the SCC should ignore their values).
That is only 1 piece of the solution. Somehow, Visual Studio and/or TFS seem to cache some information in hidden places, so it keeps insisting to use the project from the wrong branch.
So, in addition to changing the above SAK values in the project in the correct branch, you need to:
- Also check (and if wrong change) the above values to SAK for the project in the wrong branch
- Remove the references to the project in the wrong branch from the Visual Studio MRU list in the registry (HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\ProjectMRUList)
- Delete the .suo file for the good solution
- Add the project from the correct branch to the solution
- Manually modify the .sln file in the correct branch to remove the relative directory paths to the project in the wrong branch (values in keys named like SccProjectUniqueName58, SccProjectName58 and SccLocalPath58)
- Reload the solution in Visual Studio and check everything works correctly
It took at least a couple of hours to find this all out, for these reeasons: Read the rest of this entry »
Share this:
Posted in .NET, C#, Development, Software Development | 2 Comments »
Delphi XE introduced SafeIntfAsClass to cast back interface to class (via: oop – Delphi – Proxy Design Pattern – interface problem – Stack Overflow)
Posted by jpluimers on 2011/03/23
Delphi XE introduced the SafeIntAsClass to cast back from an interface to a class.
This is one of the things I really started to miss after doing a lot of .NET work (where that worked starting with .NET 1).
Older versions of Delphi did not support safely casting from an interface back to an object.
–jeroen
via: oop – Delphi – Proxy Design Pattern – interface problem – Stack Overflow.
Share this:
Posted in Delphi, Development, Software Development | 4 Comments »
The Wiert Corner - irregular stream of stuff 