Comments on: Writing Complex String Literals http://www.chrylers.com/2006/07/22/writing-complex-string-literals/ Just another WordPress weblog Tue, 06 Jan 2009 12:57:15 +0000 http://wordpress.org/?v=2.0.3 by: Sune http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-82 Sun, 26 Nov 2006 22:19:25 +0000 http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-82 Hi Kristian and Olav. The method described works regardless of whether the source code is available. It relies on auto-generating an xml documentation file. Regarding release builds -- I think I know what Olav is doing, but correct me if I'm wrong. The method does actually work in release, but you have to keep a few things in mind. As you pointed out, an optimized stack is a problem (at least for the implementation we came up with). To overcome that issue I see two options. Introduce [MethodImpl(MethodImplOptions.NoInlining)] in your code, to ensure that methods are not inlined, thus making the stack layout predictable. Or (maybe even better?), don't build your tests in release config. Instead, build your app. code in debug and release, and your test code in debug only. Of course you can still run your debug tests against both debug and release versions of your app. Using the last approach will give you a predictable stack, and hey... Release config means that the executable should be optimized using inlining, stripping debug info etc. Why would you ever compile your tests without debugging info? :-) I agree that most people builds the app code in two configurations, and they usually do the same with the test code. But I honestly think that instead of running release tests against a release app, what you really want is to run debug tests against a release config of your app. Just my two cents... Hi Kristian and Olav.

The method described works regardless of whether the source code is available. It relies on auto-generating an xml documentation file.

Regarding release builds — I think I know what Olav is doing, but correct me if I’m wrong. The method does actually work in release, but you have to keep a few things in mind. As you pointed out, an optimized stack is a problem (at least for the implementation we came up with). To overcome that issue I see two options.

Introduce [MethodImpl(MethodImplOptions.NoInlining)] in your code, to ensure that methods are not inlined, thus making the stack layout predictable.

Or (maybe even better?), don’t build your tests in release config. Instead, build your app. code in debug and release, and your test code in debug only. Of course you can still run your debug tests against both debug and release versions of your app.

Using the last approach will give you a predictable stack, and hey… Release config means that the executable should be optimized using inlining, stripping debug info etc. Why would you ever compile your tests without debugging info? :-)

I agree that most people builds the app code in two configurations, and they usually do the same with the test code. But I honestly think that instead of running release tests against a release app, what you really want is to run debug tests against a release config of your app.

Just my two cents…

]]> by: Olav http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-80 Fri, 24 Nov 2006 08:01:59 +0000 http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-80 Kristian, it doesn't work if the code is optimized. Then the stack/frame stuff is not reliable. Check the remarks section here http://msdn2.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx . I think unit testing of optimized code is important as well. Kristian,
it doesn’t work if the code is optimized. Then the stack/frame stuff is not reliable.
Check the remarks section here http://msdn2.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx .

I think unit testing of optimized code is important as well.

]]> by: kristian http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-79 Thu, 23 Nov 2006 16:52:25 +0000 http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-79 Hi Olav, right, it doesn't work unless the source code is available which causes some obvious limitations. However, for unit testing the concept works quite fine. Hi Olav,

right, it doesn’t work unless the source code is available which causes some obvious limitations. However, for unit testing the concept works quite fine.

]]> by: Olav http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-78 Thu, 23 Nov 2006 15:55:00 +0000 http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-78 you should not that the method described by Lars Thorup does not work in release builds, which in my opinion makes it useless you should not that the method described by Lars Thorup does not work in release builds, which in my opinion makes it useless

]]> by: kristian http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-26 Sun, 23 Jul 2006 07:03:36 +0000 http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-26 Hi Thomas, you are right - I did not realize this. Thank you Hi Thomas,

you are right - I did not realize this. Thank you

]]> by: Thomas Eyde http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-25 Sat, 22 Jul 2006 23:35:37 +0000 http://www.chrylers.com/2006/07/22/writing-complex-string-literals/#comment-25 C# strings with @ can be multiline. But you're right about they can't contain quotation marks. C# strings with @ can be multiline. But you’re right about they can’t contain quotation marks.

]]>