AnalogNerd wrote: complete a project you've been putting off forever. What I wanna know is where those 30 "free days" will come from.

I faced a similar situation when I had rendered the same parent script at multiple locations e.g. master / child pages and so on. You may be facing a similar scenario. Apps - Color Analyzer | Arctic | XKCD | Sound Meter | Speed Dial

Somebody knows the "Tell me 3 times and it must be true" rule (see Heinlein's "Number of the Beast")

I owe you a beer! Thank you!

Yes, I guess you are right, typically we put things that are KSS in the lounge, but you are definitely right so... Are you still here? Nothing to see here... move along please... :rolleyes: [www.tamautomation.com] Robots, CNC and PLC machines for grinding and polishing.

Hi, If you want to know how much of your private code is tested by your unit tests, there are tools to measure test coverage e.g. NCover. Such a tool may report which code lines are not hit by tests. Usually, each assembly is assigned a minimum coverage that must be reached. A 100% coverage can actually be very difficult to reach. Getting the coverage feedback can be a useful experience. You could get more conscious about how your coding style can make testing easier; branches and exceptions are usually up for discussion. Kind Regards, Keld Ølykke

What you say is what should have been done. The code should check the session variable, if it is null then go to the database and 3rd party API and calculate the value needed, and store it in the session variable for later use. In this way it's basically using the session variable for caching a value that is expensive to calculate and doesn't change often. I posted this because what the person who actually wrote this did was kind of a face-palm moment. They write the value into the session variable and then never read from the session variable again. Every time this value was needed they calculated it, then wrote the calculated value into the session variable only to never retreive it and do anything with it.

I would, but I'm worried I'd find my vendor asking for code to fix the problem they had yesterday.

AnalogNerd wrote: My new response will be "I can fail at any speed you like." Good quote, I'll use it too. :thumbsup: The report of my death was an exaggeration - Mark Twain Simply Elegant Designs JimmyRopes Designs Think inside the box! ProActive Secure Systems I'm on-line therefore I am. JimmyRopes

Solution I cheated a little. I didn't want to waste the time figuring out where my DLL was being cached. Using Windows Explorer I searched my solution folder and all subfolders for the assembly, changed the results to Details view and added File Version to the result columns. I deleted all of the old versions of the files and re-ran the tests and now they pass. Stupid %$!&!@(! MS Test.

For what it is worth changing the definition of my controller method to the following works. public JsonResult SaveLink(string ApplicationLinkId, string ApplicationId, string DisplayText, string Link)

Marcus Kramer wrote: Looks to me like the code was generated by a tool... Yes, a right tool. ;-)

throw new TableOverloadException(); Bob Dole The internet is a great way to get on the net. :doh: 2.0.82.7292 SP6a

Very well put. Thanks ryanb31.

Dave Kreskowiak wrote: You would check for mull before trying to work with the string?? I don't see how that's superfluous. "NullOrEmpty". Dave Kreskowiak wrote: poor XML files XML doesn't care much for whitespace. Dave Kreskowiak wrote: I was always taught that a method should be written to defend itself against pontentially bad data. I'm not putting an XML-validator in there :) Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]

I did as you suggested and ran into the same problem. I'll email you the link and images now.