mbunit-resharper - Project Hosting on Google Code

Older Jun 19, 2009 issue 29 (Completely trashed my Resharper installation!) reported by hainesy82 - What steps will reproduce the problem? 1. Install the plugin 2. Run visual studio 3. Oh dear, it closes again! What is the expected output? What do you see instead? What version of the product are you using? On what operating system? VS 2008 + Resharper 4.5 Please provide any additional information below. What steps will reproduce the problem? 1. Install the plugin 2. Run visual studio 3. Oh dear, it closes again! What is the expected output? What do you see instead? What version of the product are you using? On what operating system? VS 2008 + Resharper 4.5 Please provide any additional information below. Apr 04, 2009 issue 28 (SetUp method invokes to many times) reported by norbert.raus - What steps will reproduce the problem? 1. Create SetUp method within your test class 2. Create more that one test 3. Set brakepoint in SetUp method one debug ony one test What is the expected output? What do you see instead? Well SetUp method should be invoked on time, beacuse I'm running only one test. But it is invoked as many as the number of test methods in my test class. What version of the product are you using? On what operating system? Basically I've observer this issue with vesion 4, and now I'm using version 4.5. Please provide any additional information below. What steps will reproduce the problem? 1. Create SetUp method within your test class 2. Create more that one test 3. Set brakepoint in SetUp method one debug ony one test What is the expected output? What do you see instead? Well SetUp method should be invoked on time, beacuse I'm running only one test. But it is invoked as many as the number of test methods in my test class. What version of the product are you using? On what operating system? Basically I've observer this issue with vesion 4, and now I'm using version 4.5. Please provide any additional information below. Mar 04, 2009 issue 23 (While Debugging more the the selected test will be executed) commented on by jeanjacques.lafay - I also found this troublesome (either because breakpoints are unexpectedly hit, or simply because some tests are a bit long). I fixed it by making MbUnitRecursiveTaskRunner.ExecuteRecursive(TaskExecutionNode node) which is not recursive at all, slightly recursive : if (task is MbUnitTestFixtureTask) { if (node.Children.Count == 1) ExecuteRecursive(node.Children[0]); else ExecuteRecursive((task as MbUnitTestFixtureTask).MbUnitTestAction); } If I understood well, the point of not being really recursive is to avoir the TestFixtureSetup/TearDown overhead for every test if several are run at once (especially the whole Fixture), but this is not necessary if there is only one child, which is the main use case when debugging. I also needed one or two minor patches : ReflectionUtility.GetParameterTypes fails when there are no parameters, and to get the MbUnitTestTask to work correctly alone, the assembly must be managed : pass it along in the object the same way as MbUnitTestFixtureTask, then change mbUnitTestActionRunner.cs:41 mi = ReflectionUtility.FindMethod(currentAssembly == null ? methodAction.AssemblyName : currentAssembly.GetName().Name, ... I also found this troublesome (either because breakpoints are unexpectedly hit, or simply because some tests are a bit long). I fixed it by making MbUnitRecursiveTaskRunner.ExecuteRecursive(TaskExecutionNode node) which is not recursive at all, slightly recursive : if (task is MbUnitTestFixtureTask) { if (node.Children.Count == 1) ExecuteRecursive(node.Children[0]); else ExecuteRecursive((task as MbUnitTestFixtureTask).MbUnitTestAction); } If I understood well, the point of not being really recursive is to avoir the TestFixtureSetup/TearDown overhead for every test if several are run at once (especially the whole Fixture), but this is not necessary if there is only one child, which is the main use case when debugging. I also needed one or two minor patches : ReflectionUtility.GetParameterTypes fails when there are no parameters, and to get the MbUnitTestTask to work correctly alone, the assembly must be managed : pass it along in the object the same way as MbUnitTestFixtureTask, then change mbUnitTestActionRunner.cs:41 mi = ReflectionUtility.FindMethod(currentAssembly == null ? methodAction.AssemblyName : currentAssembly.GetName().Name, ... Mar 02, 2009 ReSharper-MbUnit-Beta10.zip (MbUnit Runner für ReSharper 4.0, 4.1 & 4.5) file uploaded by albert.weinert - Labels: Type-Archive OpSys-Windows Featured Labels: Type-Archive OpSys-Windows Featured Mar 02, 2009 r52 (Update Install Skript for R# 4.5) committed by albert.weinert - Update Install Skript for R# 4.5 Update Install Skript for R# 4.5 Feb 28, 2009 r51 (Updatet to R# 4.5 The PlugIn for R# 4.0 and R# 4.5 based on ...) committed by albert.weinert - Updatet to R# 4.5 The PlugIn for R# 4.0 and R# 4.5 based on the same source files with some conditional compilings Updatet to R# 4.5 The PlugIn for R# 4.0 and R# 4.5 based on the same source files with some conditional compilings Feb 24, 2009 issue 25 (MbUnit plugin not detected in Resharper 4.1 (fix included)) commented on by kswest - fixed for me too. Thanks! fixed for me too. Thanks! Feb 17, 2009 issue 23 (While Debugging more the the selected test will be executed) commented on by shanecourtrille - Agreed that this is a problem Agreed that this is a problem Oct 16, 2008 issue 25 (MbUnit plugin not detected in Resharper 4.1 (fix included)) commented on by bernardvanderbeken - Thanks, this fixed the installation problem for me! Reproduced with VS2008 / 4.1 release version. Thanks, this fixed the installation problem for me! Reproduced with VS2008 / 4.1 release version. Oct 08, 2008 r50 (abstrakt classes and methods was shown es TestFixture und Te...) committed by albert.weinert - abstrakt classes and methods was shown es TestFixture und TestMethods. Fixed. abstrakt classes and methods was shown es TestFixture und TestMethods. Fixed. Oct 08, 2008 r49 (Fixed a Bug in AssemblyHelper for TestFixture with an inheri...) committed by albert.weinert - Fixed a Bug in AssemblyHelper for TestFixture with an inherited TestBase-Class. Fixed a Bug in AssemblyHelper for TestFixture with an inherited TestBase-Class. Oct 06, 2008 issue 27 (Debugging of test fails) reported by christ...@dalager.com - What steps will reproduce the problem? 1. Clicking icon in gutter 2. selecting "debug" 3. What is the expected output? What do you see instead? This exception occurs: System.IO.FileLoadException occurred Message="The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)" Source="mscorlib" StackTrace: at System.Reflection.AssemblyName.nInit(Assembly& assembly, Boolean forIntrospection, Boolean raiseResolveEvent) at System.Reflection.AssemblyName.nInit() at System.Reflection.AssemblyName..ctor(String assemblyName) at JetBrains.ReSharper.TaskRunnerFramework.AssemblyLoader.ResolveAssembly (Object sender, ResolveEventArgs args) in c:\Agent\work\3f4db6fd459dabcd\src\TaskRunnerFramework\src\AssemblyLoader.c s:line 93 InnerException: What version of the product are you using? On what operating system? Visual Studio 2008sp1 Resharper 4.1 plugin svn revison 48 Build as Release What steps will reproduce the problem? 1. Clicking icon in gutter 2. selecting "debug" 3. What is the expected output? What do you see instead? This exception occurs: System.IO.FileLoadException occurred Message="The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)" Source="mscorlib" StackTrace: at System.Reflection.AssemblyName.nInit(Assembly& assembly, Boolean forIntrospection, Boolean raiseResolveEvent) at System.Reflection.AssemblyName.nInit() at System.Reflection.AssemblyName..ctor(String assemblyName) at JetBrains.ReSharper.TaskRunnerFramework.AssemblyLoader.ResolveAssembly (Object sender, ResolveEventArgs args) in c:\Agent\work\3f4db6fd459dabcd\src\TaskRunnerFramework\src\AssemblyLoader.c s:line 93 InnerException: What version of the product are you using? On what operating system? Visual Studio 2008sp1 Resharper 4.1 plugin svn revison 48 Build as Release Sep 17, 2008 issue 26 (Installer batch file errors when path has spaces.) reported by jason.finch - What steps will reproduce the problem? 1. Install installer when %vsdir% contains spaces (possibly os specific) 2. 3. What is the expected output? What do you see instead? Install working What version of the product are you using? On what operating system? Windows 2003 Please provide any additional information below. Surround path in Quotes is fix. What steps will reproduce the problem? 1. Install installer when %vsdir% contains spaces (possibly os specific) 2. 3. What is the expected output? What do you see instead? Install working What version of the product are you using? On what operating system? Windows 2003 Please provide any additional information below. Surround path in Quotes is fix. Sep 13, 2008 r48 committed by albert.weinert Sep 13, 2008 r47 (Back to R# 4.0 Assemblies (4.1 Assemblies not needed) and up...) committed by albert.weinert - Back to R# 4.0 Assemblies (4.1 Assemblies not needed) and updated the install.bat/uninstall.bat for R# 4.1 installation. Back to R# 4.0 Assemblies (4.1 Assemblies not needed) and updated the install.bat/uninstall.bat for R# 4.1 installation. Sep 08, 2008 issue 25 (MbUnit plugin not detected in Resharper 4.1 (fix included)) reported by adigitalaesthetic - What steps will reproduce the problem? 1. Install Resharper 4.1 over Resharper 4.0 with a working MbUnit plugin. What is the expected output? What do you see instead? The plugin is no longer detected. Please provide any additional information below. To fix this, simply add the following two lines to install.bat in the mbunit-resharper plugin zip file: === echo Trying for R# 4.0 and Visual Studio 2005 call copybat v4.1 vs8.0 i echo Trying for R# 4.0 and Visual Studio 2008 call copybat v4.1 vs9.0 i === This fixes the install for VS 2008 at least. Not tested on VS 2005. What steps will reproduce the problem? 1. Install Resharper 4.1 over Resharper 4.0 with a working MbUnit plugin. What is the expected output? What do you see instead? The plugin is no longer detected. Please provide any additional information below. To fix this, simply add the following two lines to install.bat in the mbunit-resharper plugin zip file: === echo Trying for R# 4.0 and Visual Studio 2005 call copybat v4.1 vs8.0 i echo Trying for R# 4.0 and Visual Studio 2008 call copybat v4.1 vs9.0 i === This fixes the install for VS 2008 at least. Not tested on VS 2005. Sep 04, 2008 r46 (Updated for R# 4.1) committed by albert.weinert - Updated for R# 4.1 Updated for R# 4.1 Jul 23, 2008 issue 23 (While Debugging more the the selected test will be executed) commented on by faulty.lee - That happen also when I run the test. That happen also when I run the test.

issue 23 (While Debugging more the the selected test will be executed) commented on by jeanjacques.lafay - I also found this troublesome (either because breakpoints are unexpectedly hit, or simply because some tests are a bit long). I fixed it by making MbUnitRecursiveTaskRunner.ExecuteRecursive(TaskExecutionNode node) which is not recursive at all, slightly recursive : if (task is MbUnitTestFixtureTask) { if (node.Children.Count == 1) ExecuteRecursive(node.Children[0]); else ExecuteRecursive((task as MbUnitTestFixtureTask).MbUnitTestAction); } If I understood well, the point of not being really recursive is to avoir the TestFixtureSetup/TearDown overhead for every test if several are run at once (especially the whole Fixture), but this is not necessary if there is only one child, which is the main use case when debugging. I also needed one or two minor patches : ReflectionUtility.GetParameterTypes fails when there are no parameters, and to get the MbUnitTestTask to work correctly alone, the assembly must be managed : pass it along in the object the same way as MbUnitTestFixtureTask, then change mbUnitTestActionRunner.cs:41 mi = ReflectionUtility.FindMethod(currentAssembly == null ? methodAction.AssemblyName : currentAssembly.GetName().Name, ...

I also found this troublesome (either because breakpoints are unexpectedly hit, or simply because some tests are a bit long). I fixed it by making MbUnitRecursiveTaskRunner.ExecuteRecursive(TaskExecutionNode node) which is not recursive at all, slightly recursive : if (task is MbUnitTestFixtureTask) { if (node.Children.Count == 1) ExecuteRecursive(node.Children[0]); else ExecuteRecursive((task as MbUnitTestFixtureTask).MbUnitTestAction); } If I understood well, the point of not being really recursive is to avoir the TestFixtureSetup/TearDown overhead for every test if several are run at once (especially the whole Fixture), but this is not necessary if there is only one child, which is the main use case when debugging. I also needed one or two minor patches : ReflectionUtility.GetParameterTypes fails when there are no parameters, and to get the MbUnitTestTask to work correctly alone, the assembly must be managed : pass it along in the object the same way as MbUnitTestFixtureTask, then change mbUnitTestActionRunner.cs:41 mi = ReflectionUtility.FindMethod(currentAssembly == null ? methodAction.AssemblyName : currentAssembly.GetName().Name, ...

Older