Obiwan Jacobi - All Comments

re: Basic System.Diagnostics

dotdeveloper — Wed, 11 Jul 2012 06:36:36 GMT

this was a great article.. but could you make it clear whether I can use this to log application error and write the same to Event Log in Windows 7 O.S (as on Windows Vista onwards it need Administrator role to write to event log )

re: Yet Another Logging Framework

Patrick Wellink — Fri, 21 Oct 2011 13:04:32 GMT

Spare yourself all the touble.

Have a look at Ntrace on Codeplex. !

Really works great ! and has virtually no impact on execution time.

Can be switched on/of while the program is executing.

and much much more !

re: WCF: Hosting non-http protocols in IIS 7.0

Michael — Tue, 16 Aug 2011 00:16:16 GMT

To fix the "The protocol 'net.tcp' does not have an implementation of HostedTransportConfiguration type registered" error install the "WCF non-HTTP activation components":

msdn.microsoft.com/.../ms731053.aspx

re: WCF: Hosting non-http protocols in IIS 7.0

Alexei — Wed, 13 Jul 2011 05:55:07 GMT

I have same problem

re: Seesmic Desktop Feed Reader Plugin

Marc Jacobi — Mon, 21 Mar 2011 06:02:51 GMT

Hi Keith,

Glad you like it!

The thing is, that I use standard WCF Syndication objects to parse out the feeds. So adding support for anything they don't is a bunch of extra work ;-)

Please go to the seesmicfeedreader.codeplex.com site and create an item in the Issue Tracker. Could you also provide a couple of example feed urls?

BTW: Did you know the latest version is 0.2?

re: Seesmic Desktop Feed Reader Plugin

Keith — Sun, 20 Mar 2011 18:19:39 GMT

Hi. Using your feed reader plugin and liking it. any chance you could add support for Atom 0.3? I'd try it myself, but I 'm on a Mac, and it's too much work to try to start developing silverlight programs.

re: [WPF] Data Model - View Model - View

Michal Miksovic — Wed, 16 Mar 2011 02:27:19 GMT

Nice overview. Cheers

re: The context of anonymous methods/lambda's is lost on async proxy calls in SL3 (Updated)

Marc Jacobi — Tue, 15 Jun 2010 06:18:59 GMT

Just reporting back that indeed it was a state issue with the proxy I returned from GetProxy<RequestT, ResponseT>(). I decided to leave this as is and remove all call-specific state from the proxies.

I have changed the code to a scenario where all state that is related to a service operation call is passed using a new object ServiceOperationContext. You create an instance passing it callback handlers for completion. The instance is passed to BeginRequest() of the proxy and travels as userState with the underlying service proxy call.

I've tested the solution and it surface some additional problem in the code, but once they were resolved, everything works fine.

Thanx Rogier, I owe you one! ;-)

re: The context of anonymous methods/lambda's is lost on async proxy calls in SL3

Marc Jacobi — Fri, 11 Jun 2010 05:10:18 GMT

Hi Rogier,

Thanks for the suggestion. I checked the code real quick and these instances are indeed cached! Thanx!

When I think of it now, it all seems so simple ;-) I will report back with my findings.

re: The context of anonymous methods/lambda's is lost on async proxy calls in SL3

Rogier — Thu, 10 Jun 2010 12:13:04 GMT

Hey Marc,

Is your proxy being cached by your ServiceAgent? In other words: is "_serviceAgent.GetProxy()" returning the same instance?

This would explain the behaviour you're looking at, because you are then registering 2 eventhandlers to the same proxy, which both get called when either of the two async-calls finish.

Just a thought...

grtz,

Rogier.

re: WCF: Hosting non-http protocols in IIS 7.0

Jeremy — Thu, 11 Feb 2010 19:59:40 GMT

I kept getting an error:

The protocol 'net.tcp' does not have an implementation of HostedTransportConfiguration type registered.

After much hunting and trial and error I finally stumbled on the solution. The second command you run to set the protocols for the individual website needs to have the period removed.

Weird thing was it worked on the production server, but not on the test with "net.tcp"

re: How to implement catch (Exception e)?

Gerben van Loon — Fri, 30 Oct 2009 13:43:59 GMT

Cool stuff, so familiar what you describe :)

Would even be nicer to factor this out to some kind of aspect.

re: Silverlight: Breaking the daisy chain?

Michiel van Schaik — Thu, 15 Oct 2009 06:39:03 GMT

This is where the new Reactive Framework of Microsoft can be used for. The Reactive Framework allows developers to write Language Integrated Query (LINQ) expressions against events.

As Erik Meijer explains in this (channel9.msdn.com/.../Expert-to-Expert-Brian-Beckman-and-Erik-Meijer-Inside-the-NET-Reactive-Framework-Rx) channel9 video, the Reactive Framework is the mathematical dual of LINQ to Objects.

A copy of the Reactive Framework can be found as part of the Silverlight 3 Toolkit, see martinkruszynski.blogspot.com/.../silverlight-toolkit-july-2009-rx.html

Also there will be a PDC'09 session: Rx: Reactive Extensions for .NET

re: Silverlight: Breaking the daisy chain?

Nathan Pledger — Wed, 14 Oct 2009 09:08:30 GMT

I'm getting this, too. On the negative side, it is easy to get into spaghetti code and frequent refactorings are needed to make sure things remain tidy - while restricting the possibility of deadlocks. On the plus side, I now totally "get" anonymous methods - they're practically essential for sanity's sake. Dunno if this i going to help my previous purist practices, though.

I'd be interested in your results.

re: Why I think Merging Source Code sucks

Ramon Smits — Mon, 13 Apr 2009 13:33:02 GMT

Merging branches which both have changed dramatically are very hard to do if not impossible.

Linus Torvalds says that changes in the linux kernel etc. will be done by a small team of developers. Only when the change if very well understood then it gets committed. The way that GIT works is that you first create your own personal branch to work on and when you are ready then you ask the maintainer of the /trunk branch to import that changeset. If the maintainer sees that the change conflicts too much because the main trunk has changed much because of - for example - refactoring then he just says that it will not import the change set as it is done on out dates source files. The only way to do a proper change is to add the change on an updated local branch and then asking the trunk maintainer for importing the change.

After reading that I use the same philosophy. I won't merge large code changes on out of date branches. I just delegate it to the developer that implemented the RFC to code it again as too much has changed.

Doing the merging myself is error prone and would take too much time! It would often be faster to just code the RFC myself :)

This immediately brings me to the following MUST versioning/code repository rules:

* Update reqularly (at least once a day)

* Commit often (commit when you have complete a small logical part)

* Changes must NEVER be done on the /trunk directly. First on a seperate branch, then reviewed and changed until satisfied and then be merged in to the main trunk.

Managers MUST check this or even must be notified when a developer has not committed for a while because that would indicate a possible problem.