I am trying to run NUnit in Visual Studio 2003 on 64-bit Vista but with no success.
I have set the Debug Mode of the Project to "Program" and the Start Application to "C:\Program Files (x86)\NUnit 2.4.8\bin\nunit.exe". The Test Project is set as the StartUp Project. All the code is in .NET 1.1. Unlike .NET 2.0 the processor architecture cannot be targeted (when a 1.1 executable is loaded on an x64 machine it is run in the WoW64 as a 32-bit process and utilises the 32-bit framework).
After I hit Debug > Start I receive the error window "A project with an Output Type of Class Library cannot be started directly". I am stuck and cannot get NUnit to run.
The nearest related question on stackoverflow dealt with getting NUnit to run on Vista x64 in Visual Studio 2005 "Nunit.exe cannot work on Vista 64bits if x86 build (stackoverflow.com/questions/208985/nunit-exe-cannot-work-on-vista-64bits-if-x86-build).
Additionally NUnit did not install a nunit-x86.exe from the NUnit-2.4.8-net-1.1.msi image.
My Development Environment
Vista x64 with SP1
Visual Studio 2003 (version 7.1.3088)
.NET Framework 1.1 (version 1.1.4322 SP1)
NUint 2.4.8 (installed from NUnit-2.4.8-net-1.1.msi)
I found the issue - and it had nothing to do with Vista x64.
I had set the Debug Mode of the main Project to "Program" and the Start Application to "C:\Program Files (x86)\NUnit 2.4.8\bin\nunit.exe" and not the Test Project.
Even though I had set the Test Project to the StartUp Project the Debug Mode in the Test Project was still set to the default "Project" and not to the "Application". I switched the debugging configurations around; so the main Project was set to "Project" and the Test Project contained the NUnit debugging configurations.
Summary: NUnit does run on Vista x64 in Visual Studio 2003.
IF your app is a 32-bit app, then you have to use nunit-x86.exe, it is built for testing a 32-bit application on a 64-bit system. See detail explanation here: http://www.nunit.org/index.php?p=nunit-gui&r=2.4.2
Related
I am trying to run a debug build of my software, built in Windows 10 using Visual Studio 2015 on a Windows 7 test machine.
In microsoft documentation for
Preparing a Test Machine To Run a Debug Executable
It tells me to get the .DLL files from
Program Files (x86) directory in \Microsoft Visual Studio <version>\VC\redist\Debug_NonRedist\
however the msvcp140d.dll (and associated files) located there are Windows 10 dlls, and internally link to the Windows 10 UCRT libraries that are not present or compatible with Windows 7.
I assume what I need is the location (either on my system already or downloadable from microsoft sources) of the correct DLLs to drop onto the test machine.
Can anyone help me find the correct DLLs?
We have TeamCity with 2 build agents:
VM with Windows 8.1
VM with Windows 10
Some of our projects use MS Build 12, others use MS Build 14. Some use MS Test 12, others use MS Test 14.
I installed the build tools for Visual Studio 2013 and Visual Studio 2015 on both machines. All builds were succesful, but our tests weren't.
Some of the projects configured with MSTest 2013 had failing tests on the Windows 10 VM and some of the projects configured with MSTest 2015 had failing tests on the Windows 8.1 VM.
The exception I get is the same for all the tests. This is the one I get on the Windows 8.1 VM:
System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.
This is the exception I get on the Windows 10 VM:
System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.
Everything worked fine on all of our development machines (some devs use VS 13, other devs use VS 15).
The problem was fixed on the Windows 10 VM by installing Entity Framework 6 Tools for Visual Studio 2013.
As of now the Windows 8.1 VM has the tools for VS 2013 and the Windows 10 VM has the tools for VS 2013 and VS 2015.
As of Visual Studio 2015, the tools are included in the installation of Visual Studio itself. I'm not going to install VS on a build agent (the Windows 10 build agent is also a development machine, that is why it already has the tools installed)...
How can I get this to work on my Windows 8.1 VM, with or without installing the EF tools? Shouldn't installing the build tools be enough for a build agent?
I have developed an application with Visual Studio 2012. I have also created a setup.exe with Install Shield 2010 Premium for my application. My development environment is Windows 8 64-bit, the application is compiled under Release Win32. The developing language is C++.
After building setup.exe, I ran it on another computer that is running on Windows 7 64-bit. An error message box pops up saying MSVCP110.dll is missing or not configured to run on Windows. Any ideas as to why this may be?
I tried installing Visual C++ Redistributable for Visual Studio 2012 (http://www.microsoft.com/en-au/download/details.aspx?id=30679), but it still gives the same error.
Any help would be appreciated.
MSVCP110.dll is really part of VC++ Redistributable package.
Try to install both versions of them: x86 and x64 if your machine is 64 bit.
For 32bit machine you need only x86 package.
Please help. I have a web application that was built in VS2010 and we are using the CR plugin for 2010 and everything works perfect on our local machines. When we go to deploy the web application to Server 2008 the application runs fine until we try to get to a report. When we get to a report we receive...
Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' or one of its dependencies. The system cannot find the file specified.
We have installed the CR2010 runtimes and the file log4net.dll version 1.2.10.0 is in the GAC so we are not referencing it in the application. When we add it as a reference we get this error no matter where we are in the application, not just on the report pages. Please help!
I received the same error message after accidently installing the x86 version of the crystal reports redist on a x64 machine.
Installing the correct x64 redist fixed the problem - http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_redist_install_64bit_13_0.zip
We just ran into the same problem and it turned out to not (in our case) be the version of the Crystal Reports redist (we installed the 32 bit versions on our 64 bit machines. The way we were able to fix the problem was to
Navigate to your virtual directory Application Pool -> Advanced Settings -> Set Enable 32-Bit Applications to True
and changed the managed pipeline mode from Classic to Integrated. After that we no longer got errors of the missing log4net dll.
We also had the same issue with the 64-bit redistributable installed. In our case, we set the "Enable 32 Bit Applications" setting to FALSE in the advanced Application Pool properties and that resolved the issue.
If you have a x86 development machine and your web server is a 64-bit machine, you may be running into the problem discussed here:
http://social.msdn.microsoft.com/Forums/en-US/vscrystalreports/thread/546059a6-7179-4027-8f16-822ac6dc189a/
Visual Studio is automatically deploying a 32-bit log4net.dll into the 64-bit web server, even if you don't have it referenced in your project. Just delete the log4net.dll from your bin directory once deployment has finished because it's not actually required by the CR runtime to work.
For me I had a VB Application project and under Compile options, I had "Any CPU" selected for Target CPU and I also had the "Prefer 32-bit" checked. When the compiled app ran on a 64 bit machine, which only had the x64 runtime installed it could crash with this error, because it tried running as a 32 bit app and wanted the 32 bit runtime. Unchecking this option and recompiling made it work correctly.
Install Crystal Reports for Visual studio Runtime engine for .NET Framework 64 bit
Solved my problems.
I have 2 NLB 2008 R2 Servers, my IISs are configured to run in x32.
In one server I have installed x64 and x32 SAP redist and I have the error, in second server only the x32 and works.
To get the first server work I uninstalled all versions and reinstalled only x32, but the server start work only after a reboot.
Bye
In my case I had the error while developing with Visual Studio 2022. I did what the other answers here say, installed Runtime 64-bit, because my machine is 64 bit, and then:
(in Visual Studio) Project Debug Properties > Web > Servers > Change Bitness to x64 (using IIS Express)
I can't run a debug sdk application because it requires both VC 8 and VC 9 versions of the CRT. But it only requires visual studio 2008 for plugin dev, which is what I need.
How do I install the debug runtimes from 2005 on to a Windows7 machine? I can't figure out how to make them run app local nor can I copy anything into the winSxS folder without a trusted installer.
Refer to this post.
As per this the debug dlls can be found at:
For Visual Studio 2005:
C:\Program Files\Microsoft Visual
Studio 8\VC\redist\Debug_NonRedist\x86
For Visual Studio 2008:
C:\Program Files\Microsoft Visual
Studio
9.0\VC\redist\Debug_NonRedist\x86
Also as per what I know you need not have these dlls in the WinSxS folder. Even if these dlls are present in the same directory as your application exe is, it will do.
Anyways using debug dlls in production environment is not recommended.
In case you elevate your application, make sure you set the 'Start in' path to the application home/install directory or add the path to the VC++ debug dlls to the PATH environment variable.
You must install visual studio to get the debug CRT. This will be moot as soon as we don't need 2005 or 2008 again.
You can create a simple setup project (vdproj) which pulls in the debug merge modules.
This works fine up to Visual Studio 2010 (VS10) but is not supported for 2012 (VS11) and later :o(
You must install the C++ compilers to get the debug CRT, but you don't have to install all of Visual Studio. Instead, use the web install of the Windows SDK to install the compilers. The Windows 6 SDK includes the VC8 compilers, the Windows 7 SDK includes the VC9 compilers and the Windows 7.1 SDK includes the VC10 compilers.