DLL is not a valid win32 aplication

[Atom1]

I recently migrated from VS 2019 to VS 2022. When I try to run debug on this code, I get a message box saying dll is not a valid win32 application. I can build it, but I can't run debug. It all worked with 2019, so what am I missing?

#include <string>
#include <stdlib.h>

using std::string;

char __stdcall StringFn(char StrFromTS)
{
	return StrFromTS;
}

double __stdcall TestFunction(double DblFromTS)
{
	return DblFromTS * 2;
}

[kigar64551]

A DLL can not be run; at least not directly. Only a program (EXE file) can be run.

Does your VS solution contain a project that is a program (EXE file)? If so, then try setting that project as the "startup" project.

Also, be sure that the EXE file and any required DLLs are built for the same target architecture! For example, if the EXE file is built for the "x86" architecture, then all required DLLs need to be built for the "x86" architecture too. If the EXE file is built for the "x64" architecture, then all required DLLs need to be built for the "x64" architecture too. And so on.

Furthermore, make sure that your system supports the target architecture! For example, you can cross-built binaries for the "arm64" architecture on a x86/x64 machine, but you can not run the resulting binary on that machine, obviously.

[deleted account xyzzy]

For VS 2022 a bit of a refresher on how to create and use a library, static and dynamic, might be helpful:

Walkthrough: Create and use a static library (C++)
https://learn.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-static-library-cpp?view=msvc-170

Walkthrough: Create and use your own Dynamic Link Library (C++)
https://learn.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp?view=msvc-170

As both walkthroughs point out you need to create an executable program to use the library created. The VS solution framework allows you to "tie together" the library and user program project's together. Compiling both so they are the same end architecture. x86, x64.

When you have your solution set up with your two projects I really recommend you use the "batch build" feature so you can build both projects together. Helpful when making a change in either project's code, Especially if you are creating a static library.

With the batch build you can recompile both projects "from scratch" if needed. Sometimes the partial build doesn't work.

[Atom1]

I understand a dll cannot be run by itself, but the whole objective of the project is to create a dll, which it does, and the dll works. When I build the solution, it succeeds without errors.

Perhaps I misunderstand what the debug function is for. I've assumed it is to look for errors in the project or solution or their components that need to be corrected before whatever is supposed to be built can be built. Obviously, this is not the case, but I'd like to understand why I'm getting the warning when I run debug. Should I just ignore it?

[deleted account xyzzy]

There are two different types of ways to compile, Release or Debug. The debug compile includes a lot of runtime code that allows for "easy" debugging within the VS IDE if the program is started within the IDE. It doesn't look for code errors, that is done by the compile process when it is invoked. The VS IDE can also detect possible errors before the compile process is started.

So, yeah, you misunderstood what the Debug configuration does.

Release doesn't contain all the debug info, only the code needed to run.

What is the exact warning you are getting when you run your compiled solution in debug?

FYI, I just tried the two walkthroughs in my VS 2022 IDE. Set both solutions, dynamic link and static libraries, so I could batch build for x86 (32-bit) and x64. Each version of the libraries and their client programs compiled and executes without an issue.

[deleted account xyzzy]

I just gotta ask, are you trying to create and consume a static or dynamic link library?

There are pros and cons, benefits and detriments, for either type of library.

[kigar64551]

Perhaps I misunderstand what the debug function is for. I've assumed it is to look for errors in the project or solution or their components that need to be corrected before whatever is supposed to be built can be built. Obviously, this is not the case, but I'd like to understand why I'm getting the warning when I run debug. Should I just ignore it?

Nope. "Debug" simply runs the program, just in the debugger. This means that when a serious error is encountered while the program is running (i.e. when the program "crashes"), then it won't just terminate, but instead the program will be "suspended" and control is handed over to the debugger, so that the program state can be inspected. For example, you can inspect the call stack to see where it crashed.

👉 https://en.wikipedia.org/wiki/Debugger
👉 https://en.wikipedia.org/wiki/Call_stack

But this means that you need a program (EXE file) for debugging. A DLL can not be debugged on its own! If you want to debug a DLL, then you need a runnable program (EXE file), which runs in the debugger and which serves as the "host" for the DLL to be debugged.

[Atom1]

Ok, I get it now. Thanks for clearing that up for me.

[seeplus]

Also just a small point. if you want to debug a dll then the dll needs to be built using the debug build. You can mix debug/release builds for .exe and .dll(s) but you'll only be able to use the run-time debugger properly for those built as debug build. Usually whilst developing then debug builds are used until you're happy that the program works OK. Then the program is re-built as release and tested again. It is possible that a program gives the appearance of working ok when built as debug but doesn't when built as release. Extensive testing is always required!