• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Opening old Visual Studio project with 2019, throws tons of errors with provided libraries

MajinCry

Platinum Member
Having learned Pascal and C# in order to mod Bethesda games, I'm moving onto C++ in order to create .dll files for New Vegas' script extender. But the provided Visual Studio project is of a much older version than 2019. After VS updates the old project, compiling fails spectacularly.

For some reason, the libraries provided as part of the script extender do not compile. The example project, without modifying any of it's code, compiles fine. It's the libraries that throw the errors. Here's the log: https://pastebin.com/raw/xgJUAPjP

The source can be downloaded here, it's in the main archive: http://nvse.silverlock.org/

Any idea how to work around this?
 
The "namespace std has no string" is due to a missing header. Add the necessary #include <string> to the file in question.
 
The "namespace std has no string" is due to a missing header. Add the necessary #include <string> to the file in question.

Aye, I did that, and it throws a bunch more errors. Asked on the MSDN forum how to handle them, and those fixes just made different errors for the same function occur.

Found out that all these errors don't occur when using the 2013 toolset. There's only one, and I can't for the life of me figure out why it's being thrown:
Despite changing the output directory for the project, it's still sent to that incomplete path. Worse, the error list doesn't say where in the project the copy command is issued, so there's no way to see if the variable is being overridden by a piece of code preceding the copy command.
 
Try using a directory without a space in the path? Some commands can be a bit screwy with paths that contain spaces.

EDIT: And make sure VS is running with Admin privileges, that can mess up copy ops.
 
Last edited:
The error still occurs after both running as administrator, and changing the output directory to S:\Games\test the error still occurs:

Code:
Severity	Code	Description	Project	File	Line	Suppression State
Error	MSB3073	The command "copy "S:\Games\test\nvse_plugin_example.dll" "\Data\NVSE\Plugins\nvse_plugin_example.dll"
:VCEnd" exited with code 1.	nvse_plugin_example	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets	132
 
Actually, I just noticed that it outputs the .dll to the directory after I checked it on a whim. Odd that it throws the error, but I assume the .dll is just fine?
 
You're probably better off installing the version of Visual Studio that the project was created in. MS still lets you download versions as old as VS 2010: https://visualstudio.microsoft.com/vs/older-downloads/

I'm somewhat rusty on C++ in Windows, but I don't think that MS makes any guarantees about ABI compatibility between different Visual Studio compiler versions. If you are working in 2019 while using a script extender and other tools you've downloaded that were compiled with older VS versions, there's a pretty decent chance of you hitting some weird and very hard to diagnose issues. Native development using C++ is much less forgiving of this kind of thing than development using more modern languages that don't compile directly to native code.
 
The solution was to install VS 2013, which adds the 2013 toolset to 2019. That way, you can have all the new features of the 2019 IDE, while using the C++ compiler for 2013.
 
Just a note, this might be a great time to consider moving your build system to something a little more modern (like CMake).

Once you get it working, there is little chance that you'll need to worry as much about newer versions of visual studios supporting it or not.
 
Back
Top