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?
Related
The goal
I would like to use a Windows Server 2016 (x64) for remote debugging of UWP applications. The reason? My working PC still runs a Windows 7 instance and it is not possible to deploy an UWP app on a Windows 7 machine.
The problem
I have already installed the Remote Tools For Visual Studio 2015 on the Windows Server 2016 machine and started it on port 4020. Authentication mode was set to "None". I have enabled Developer mode on the server as well. Also I have set up my project in Visual Studio to use the remote machine for debugging.
The problem is, whenever I try to deploy (just deploy, not even debug) my solution to the server, the following happens:
Visual Studio shows the following output:
Deploy started: Project: MyProject.UI.Uwp, Configuration: Debug x86
Starting remote deployment...
Reading package recipe file "C:\SourceCode\MyProject\MyProject.UI.Uwp\bin\x86\Debug\MyProject.UI.Uwp.build.appxrecipe"...
and then hangs forever.
In the meantime, remote tools on the server show the following output:
UserAbc connected.
This indicates there must be at least some communication between my Windows 7 PC and the target Windows Server 2016 machine.
No error message is displayed whatsoever (neither in Visual Studio, nor in the Remote Debugger).
The question
Any idea why the deployment hangs forever without an error message? Or am I trying to achieve an impossible task? Is the Windows Server 2016 capable of running UWP apps at all?
Update
I installed VS 2015 Update 3 directly on the Windows Server 2016. I was able to create and debug a simple UWP app directly on the server so the server is clearly able to run an UWP app. However I am still unable to make the remote debugging working. Maybe the problem is completely on my local Windows 7 PC and has nothing to do with the Windows Server. It is strange that the process hangs while "Reading package recipe file". Could it be that an antivirus is intercepting?
Thanks for your feedback. There is a similar issue when I try to deploy the UWP project to a remote machine on Windows 7. We have communicated about this using our internal channel. Unfortunately, Visual Studio 2015 or Visual Studio 2017 doing UWP development on Windows 7 is not a recommend scenario.
For Visual Studio 2017, using Tools for UWP App Development is not applicable on Windows 7. See Visual Studio 2017 Support for Windows Development.
For Visual Studio 2015, the official support for Windows Universal is "Build only". We can use Visual Studio 2015 to build UWP apps on Windows 7, but some other Visual Studio features for Windows Universal development may be degraded. See Visual Studio 2015 Support for Windows Universal, Windows Store, and Windows Phone App Development.
To develop Windows Universal Apps, Windows 10 is strongly recommended. With Windows 10, you can get the best experience of UWP development.
What is best way to do remote live gdb debugging and use Visual studio as the front end.
In my case: I have a C++ application (compiled for debugging) running on a Linux server
Can I use Visual studio on my windows machine as a front end to do
live debugging on the C++ application. Is this even possible for a
large scale application (OR)
If above is not possible, can I use eclipse on my windows or on a different linux box to do the same remote live debugging
Any other better IDE options ?
Thanks.
You can easily do it with VisualGDB:
Build your app on the Linux machine and ensure that you can run it.
Install VisualGDB on your Windows machine with Visual Studio.
Run the VisualGDB build server on the Linux machine.
In Visual Studio, create new project, select C++->VisualGDB
In the wizard select Linux Application -> Import Existing -> Import from Remote machine
Select the directory where you have built the Linux app. If it's not based on GNU Make, also specify the build command line.
Specify whether you want to synchronize IntelliSense directories with Visual Studio.
On the last wizard page specify the executable name of your project so that VisualGDB knows what to debug.
When you press "finish", the Wizard will create a Visual Studio wrapper project around your Linux project so that you can edit the files, built the project and debug it from Visual Studio.
There's a more detailed tutorial here: http://visualgdb.com/tutorials/linux/import/
You can try WinGDB.
It is an extension for Visual Studio allowing to develop and debug programs with GDB. Here is how to setup Remote Linux development using WinGDB.
I don't think it's possible using Visual Studio.
It should be possible using gdbserver/gdb combo, but on Windows machine you will need special build of gdb that targets linux. I never tried this, but it should be possible to build.
If you can get this working, then you can use Eclipse or any IDE that supports GNU tools.
Just some recommendation:
You can install a free X server on your Windows machine, such as Xming or Xorg in Cygwin. Then you can do Linux native debugging with eclipse. Just display the eclipse GUI to your X server on Windows. You can interactive with the GUI on your Windows machine.
Now possible with VS2015 + GDB extension, reas MS blog post here: http://blogs.msdn.com/b/vcblog/archive/2015/11/18/announcing-the-vs-gdb-debugger-extension.aspx
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.
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