Visual Studio Weirdness
-
I have a dot net 8.0 C# DLL project that holds a reference to a C++ .net 8.0 mixed mode DLL project. Whenever the mixed mode project is rebuilt, then none of the projects that depend upon it will load the previous build of the mixed mode DLL. It gives a library version not found error if I try to run the previous build. This is annoying because this happens whenever the mixed mode DLL is rebuilt, even if there are zero code changes in that project. Just where do you think Visual Studio is managing this auto-incrementing build number that is disrupting my development feng shui? When I open the Properties dialog for the mixed mode DLL, I can't find anything that looks like it implements an auto-incrementing build number. Remember, this would be the Properties window that is presented for native projects, not dot net projects.
The difficult we do right away... ...the impossible takes slightly longer.
-
I have a dot net 8.0 C# DLL project that holds a reference to a C++ .net 8.0 mixed mode DLL project. Whenever the mixed mode project is rebuilt, then none of the projects that depend upon it will load the previous build of the mixed mode DLL. It gives a library version not found error if I try to run the previous build. This is annoying because this happens whenever the mixed mode DLL is rebuilt, even if there are zero code changes in that project. Just where do you think Visual Studio is managing this auto-incrementing build number that is disrupting my development feng shui? When I open the Properties dialog for the mixed mode DLL, I can't find anything that looks like it implements an auto-incrementing build number. Remember, this would be the Properties window that is presented for native projects, not dot net projects.
The difficult we do right away... ...the impossible takes slightly longer.
If I understand the question correctly it is not a 'version number' A dll has a header that describes the contents. That includes things like a version number but it also includes the code type which is something like '32bit', '64bit' and 'any'. There are other thinks in there like the full name, encryption info, etc. I think the following page discusses some of this. PE Format - Win32 apps | Microsoft Learn[^]
-
If I understand the question correctly it is not a 'version number' A dll has a header that describes the contents. That includes things like a version number but it also includes the code type which is something like '32bit', '64bit' and 'any'. There are other thinks in there like the full name, encryption info, etc. I think the following page discusses some of this. PE Format - Win32 apps | Microsoft Learn[^]
Yes, but it would refuse to load the DLL even if there were no code changes or assembly property changes. I think I have solved it however. There is a file in the DLL project named AssemblyInfo.cpp, and it contains an assembly attribute named AssemblyVersionAttribute. And it was set to L"1.0.*". I think this was causing the problem. The asterisk means that it should autoincrement the version number. I changed the value to L"1.0.0" and it no longer fails to load the DLL if the DLL is rebuilt. Thanks for reading my post and for your input!
The difficult we do right away... ...the impossible takes slightly longer.
