I found a round about solution, but think it would be nicer to find the information in the object model from the function arguments. The round about solution was to read the XSL document (XmlReader) and extract the <xsl:stylesheet xmlns: attributes and from those create a XmlNamespaceManager (and XmlNameTable). The XmlNamespaceManager was passed to the XSL Extension class constructor which places the value in a private class variable that is used in the .Select argument list. This makes the wrapper program have to read the XSL document twice, once to find the stylesheet element and close/reopen to pass to XslCompiledTransform. It works and now the extension function evaluate can accept XPath with namespace prefixes.
When my automated build runs on the build server all of the tests pass.
If I run one of the failed tests by right clicking inside the test (Visual Studio 2010) and clicking "Runs Tests" it fails.
If I run the same test using the little circle in the left gutter from ReSharper it passes.
This leads me to believe it has something to do with the Host type? But I am not sure.
The failure in the test has to do with a Method Not Found exception. The class under test, ClassA, inherits from ClassB (from a referenced assembly). Class B has a method on it that is being called in the code, and when the tests fail they do so because the method cannot be found.
Does anyone have any ideas about what might be causing this or how I can fix it?
EDIT: As it turns out MSTest is not copying the right version of my assembly to the Out folder, which would make sense why it can't find the method. The correct version is referenced in the Test project, not sure why it is hanging on to the old version, or where it's getting it from.
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.
Honestly the best way to learn how a runtime works is to learn how to debug it at the lowest levels. Read every single article here: Tess Ferrandez on MSDN[^]. Read if from start to end (well, actually end to start) and you should have really good in-depth knowledge (granted, reading and digesting that whole blog will probably take a few months). Real-world experience/stories sticks a lot better than raw theory (at least in my experience).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore, Dream. Discover.
can anyone help explain what might happen to a .NET application if file system crash? Simply put, should the apps pop up warning/error reminding that file system is carshed? How does your apps deal with file system crash?
for example, a designated folder got changed, not able to write into it, the system shall pop up error message, right? so I have to make specific error exception/message for this kind of case, otherwise the system just gave general error message, am I right?
As the inability to save to a certain location is a predictable exception (e.g. the user attempts to save into the Windows folder on Windows 7 when running with normal permissions), it's always a good idea to protect against this type of exception.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
can anyone help explain what might happen to a .NET application if file system
In general - no.
How does your apps deal with file system crash?
Whatever the business requirements suggest and reasonable extrapolation from that.
For example I don't try to do anything at all about the file system filling up for a server. Can it happen? Yes. If it does what can I do? Nothing. I do however expect that any reasonable operations setup would take into account file system monitoring.
As another example if I can't read a configuration file that the server requires on start up then besides logging an error I can do one of the following
- Start with default values.
- Exit the server.
The choice depends on what was supposed to be in the configuration file that I was reading.
(Note that a logging solution MUST be implemented such that a logging failure does not stop the application from running.)
A stand alone user application should probably do something different. If it cannot read/write to the fle system then it should report that to the user.