I have been using nunit with visual studio 2010 on a windows 7 64-bit pc.
I am able to open the nunit gui and run my unit tests. If I then change one of the unit tests and try to rebuild, I am getting a file locking error as follows -
Error 1 Unable to copy file "obj\Debug\myProject.Tests.dll" to
"bin\Debug\myProject.Tests.dll". The process cannot access the file
'bin\Debug\myProject.Tests.dll' because it is being used by another
process. myProject.Tests
I have used process explorer to verify that it is the nunit-agent.exe that is locking the dll.
I have noticed via tools > test assemblies that the nunit.exe is running under clr version Net 2.0 and nunit-agent.exe is running under clr version Net 4.0. could that have something to do with the problem? If so, how can I fix it? If not, does anyone have any idea what else may be going on?
Thanks for any thoughts.
I think this has to do with the placement of my test project. Initially, I was putting the nunit test project in a seperate directory from my dll files. I was thinking that I would keep all of my test projects in one centralized location.
I them moved my test project into the same location as my test dlls under my visual studio projects. After that, it seems to be working correctly.
I think this has to do the shadow copy. I read in the nunit group on google that the .net framework will only shadow copy assemblies in the application base or it's subdirectories.
This led me to try creating the nunit test project within my application base and that seemed to work.
Hope that makes sense.
Thanks
I also faced the exact issue, however czuroski's answer did not work for me (although I think that we are in effect talking about the same thing).
What did work for me was to ensure that in NUnit I set the Project Path and Project Base were pointing to the same root application folder under Project -> Edit. I re-saved my existing Nunit project to the same directory as my VS sln file.
Another thing to check is to make sure that Shadow Copy is enabled in Nunit -> Tools -> Settings -> TestLoader -> Advanced -> Enable Shadow Copy
try this, Tools > Settings > Test Loader > Assembly Isolation > Default Process Model > Run tests in a separate process per Assembly.
Related
I have a large solution of dozens of projects. Since yesterday (and for no good reason that I can find) the projects are refusing to build, with Visual Studio's build output window simply stating (eg)
1>------ Skipped Rebuild All: Project: Api.Models.Common ------
There are already a few similar q/a's here about the reasons why VS may decide to skip a build (Configuration not set to build, or set to build wrong target). I'm not interested in guesses as to why this isn't building. I'd really like answers to help me diagnose this, and have Visual Studio tell me why it thinks it can skip the build.
Is there a way to have VS generate anything more detailed than Skipped rebuild for example? It must be calling msbuild under the covers right? So can I have Visual Studio pass additional parameters to msbuild so that it generates diagnostic log output?
(For what it's worth - calling msbuild from the command line builds the projects as expected, so it seems like my issue is something quirky that VS is doing).
I'm using VS 2017 - 15.9.4
If you have any unload projects, you must load it or you remove it in solution.
Note: My unloaded project was the result of a permission issue. VS warned that a project was configured to use IIS. To run the project with IIS required launching VS as an administrator.
This was happening in my solution with Visual Studio 2019. I just migrated my applications from .Net Framework 4.6 to .NET5, almost all the projects were not building, it gets always skipped. The reason was that after the migration the tool upgrade assistant was not setting the Target Framwework as in the preceding image (Right-click on the project and then click on Properties).
After setting it to the right framework, in my case, it was .NET 5.0, the project started to build.
I have a WebAPI project in Visual Studio 2013. If I build the project in Visual Studio, in the bin/ directory I see a file called MyProject.dll.config, which represents the web.config file at build time.
However, if I execute MSBuild from the command line, the .config file is missing, but all other files are present.
> msbuild.exe /t:build /v:q /p:Configuration=Debug /nologo \
D:\Workspace\MyProject\src\MyProject.sln
What gives? Why isn't the .config copied?
For deploying a web project or a web api project, the fact that there's no $(TargetName)$(TargetExt).config isn't a big deal. At run-time, IIS will use Web.config to figure out everything it needs for your assembly.
BUT!
If you're using a Web App or Web Api project as the basis for testing* then you can hit some snags. In particular, when it comes to assembly binding redirects (as is the case with something within the bowels of MVC which still relies on Newtonsoft.Json 4.5.0 when the current version at time of writing is 7.0.0). A colleague had a similar issue with another assembly his test project was depending on.
Now when you run your tests through Visual Studio (eg, via Resharper), they all work just fine. However, when your tests get to the CI server and they are run by nunit-console, you'll see assembly load errors. Not pretty. This is because of the described behaviour where VS is sneakily copying the .config file to the correct output and msbuild isn't. However, you can work around this with a post-build build event:
copy $(ProjectDir)Web.Config $(TargetDir)$(TargetName)$(TargetExt).config
This has resolved my issues with redirects. I hope it helps someone else.
You may ask "Why use a Web App or Web API project as your test project?". A Web* project is a lot more comfortable to deal with as a base for a test project which deals with .net assemblies and JavaScript tests as JavaScript is properly recognised (syntax highlighting) and there's a Scripts folder which has the quick "Add -> Javascript File" menu item for itself and descendant folders, so I prefer to use this instead of a plain Class Library project.
When I create a WebAPI project the web.config Copy to Output Directory is set to Do Not Copy by default. Did you select the Web.config in Solution Explorer and set this to a copy action?
I'm at a loss to explain why it seems to copy for you with the IDE build but NOT the msbuild cmd you show, this is not the behavior I see with a fresh WebAPI project in 2013.
I wonder has anyone come across with this issue where the MSTest Unit Test doesn’t show up in the new Unit Test Explorer.
I’m running Windows 7 (32bit). I downloaded the VS11 Developer Preview from the link below. http://www.microsoft.com/download/en/details.aspx?id=27543
I created a sample C# Console App, and add the Test Library from the MSTest project template. Then I created a sample Unit Test, and rebuild the solution. When I open the Test Explorer (View->OtherWindows->UnitTest Explorer) I do not see any tests loaded.
I only see a message saying…
“No test discovered. Please build your project and ensure the appropriate test framework adapter is installed”.
I assume the MSTest adapter is automatically installed. If not I’m not even sure how to install an adapter.
I could be missing something here but I cannot figure it out. Has anyone experiencing this issue?
Found out that at this only works with Windows8. (At this stage)
More info
http://jerssoft.blogspot.com/2011/09/vs11-unit-test-explorer-acercamientos.html#more
(you need to translate to English)
"Of course, all this work the right way if we have properly configured and in the final version , since according to understand, if you want to try this plugin, you need to be working with Windows 8 :) "
http://geekswithblogs.net/lbugnion/archive/2011/09/24/running-unit-tests-in-visual-studio-2011-and-windows-8.aspx
If you are using VS Ultimate version of VS 11 developer preview, then it support MStest based unittesting for Windows7 style apps/projects if that is what you were trying out. It is possible that you are hitting a bug. Will it possible for you to share your repro steps?
Thanks,
Abhishek Agrawal
Program Manager, Visual Studio,
Microsoft Corp
This wasn't working for me using Visual Studio Express 2012 Web RC, but I got it going eventually.
I added the reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework which I found in C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies
I made sure this was set to Copy Local but probably not required.
Then I tried cleaning and rebuilding but with no effect. I made sure I didn't have any testsettings selected (Test Menu > Test Settings > Untick the testrunconfig if selected), then changed my Test > Test Settings > Default Processor Architecture to x64 (my machine is x64).
Then I cleaned and rebuilt the solution and my Test Explorer was populated when I click Run All.
I just downloaded Microsoft Visual C++ and am trying to run a simple hello world. However, when I go to debug, I get the error "Unable to start program 'C:\Users\Sterling\Documents\Visual Studio2010\Projects\test\Debug\test.dll'"
And thats it. It doesn't say WHY it can't start it...it just says it can't. Has anyone experienced this? And know an answer? I'm thinking about just reinstalling it, but was hoping to find an easy solution first. Is there a separate program I need to start .dll files? I just got this laptop about a week ago so I may not have it yet. This is on Windows 7. Thank you for any help.
You have built your project as a DLL. You cannot run DLLs standalone. If you meant to build it as a program (.EXE), change the Project Settings.
Right click Project in Solution Explorer, click Properties - edit Configuration Properties -> General -> Configuration Type to be "Application (.exe)".
If you want to build (and run) your project as a DLL, you will have to also write a program that uses it in order to to test it. You could do this as a separate 'TestDll' EXe project in the same solution as your existing DLL.
Whenever I publish my MVC web application in VS 2010 via the One-click publish feature (I'm not doing any web.config transforms or anything fancy - yet!). The next time I come to build the app I get the following error:
It is an error to use a section registered as allowDefinition='MachineToApplication'
beyond application level. This error can be caused by a virtual directory not being
configured as an application in IIS. in ...MyWebApp\obj\release\package\packagetmp
\web.config
A new copy of the web.config file is indeed created by VS2010 below the ...MyWebApp\obj\ folder so I deleted the whole obj folder and I was then able to build again.
But I shouldn't have to do that each time I publish - I must have something configured incorrectly - can anyone help please.
Thanks.
This is unfortunately a known issue with Publishing a web application to the file system. This still affects the release version (RTM) of Visual Studio 2010. It's not limited to the Beta or RC versions.
This problem "bit" me also, and I too was having to manually delete the Debug and Release folders inside the obj folder within my web site solution folder.
The real answer for an automated "workaround" can be found in this answer to the other Stack Overflow question:
Why do I randomly get a “error to use section registered as allowDefinition='MachineToApplication'” when building an MVC project?
In a nutshell, you need to delete the web.config files from either the Debug or Release folders (or both!), and that's achieved with a pre-build command (configured in the Build Events tab of the Project Properties page of your solution):
del "$(ProjectDir)\obj\Debug\Package\PackageTmp\web.config"
del "$(ProjectDir)\obj\Release\Package\PackageTmp\web.config"
Personally, I delete the entire obj folder since all those files are re-created with each build anyway.
I have just found a work around for this that has worked for me, open the .csproj for your web project and change the node under the Project\PropertyGroup node to this:
from this:
<MvcBuildViews>true</MvcBuildViews>
to this:
<MvcBuildViews>false</MvcBuildViews>
This has worked for me, hopefully it will work for you also.