I want to make a type lib (tlb) having another name than dll:
c:\windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe "c:\program files (x86)\sample_program\Library.dll" "c:\program files (x86)\sample_program\TypeLibname.tlb" /codebase
When executing this line in Powershell, no errors occur.
Microsoft .NET Framework Assembly Registration Utility 4.7.3056.0
für Microsoft .NET Framework, Version 4.7.3056.0
[...]
Types have been registered
So a tlb must have been generated. Though the tlb is put everywhere, but not in the desired directory "c:\program files (x86)\sample_program\"
Any idea ?
Thank you !
All the best,
Stephan
Just had to insert /tlb and change the expression into:
c:\windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe "c:\program files (x86)\sample_program\Library.dll" /tlb:TypeLibname.tlb /codebase
Related
The Poco Libraries can be really powerful and useful... but also stubbornly hard to build :-( I am now several days into a process of trying to upgrade from:
Poco 1.9.0, win32 build, including NetSSL_OpenSSL and Data/MySQL, on Windows 7, using MS Visual Studio 2015 successfully built via buildwin.cmd script from Windows Explorer since April 2018
to:
Poco 1.10.1, win32 and x64 builds, including NetSSL_OpenSSL and Data/MySQL (32-bit) or Data/PostgreSQL (64-bit), on Windows 10, using MS Visual Studio 2019, built via any means at all.
So far I cannot make the build process budge in any significant direction from my old build to my new target via any means... except possibly via CMake.
Since CMake appears to be the preferred way to build Poco, and nothing else (e.g. buildwin.cmd) works as expected, I am trying to rebuild the 32-bit DLLs so I can test with older proven components in my application. It looks promising. But the crypto build complains:
LINK : fatal error LNK1104: cannot open file 'libcrypto.lib' [S:\3rdparty\Poco-build32\Crypto\Crypto.vcxproj]
That's strange: in the entire Crypto.vcxproj file, there is no mention of libcrypto.lib at all, only libcrypto32MD.lib and libcrypto32MDd.lib. Why is it even looking for libcrypto.lib? Even so, if it is supposed to be finding libcrypto.lib, why doesn't it succeed when it is freshly installed in C:\Program Files (x86)\OpenSSL-Win32\lib and OPENSSL_ROOT_DIR is set to C:\Program Files (x86)\OpenSSL-Win32? What am I missing? I got to this point via:
cmake -HS:\3rdparty\Poco -B S:\3rdparty\Poco-build32 -G "Visual Studio 16 2019" -A win32
cmake --build s:\3rdparty\Poco-build32 --config RelWithDebInfo
UPDATE: in case I modified anything while trying to make it build in other ways (buildwin.cmd, Batch Build in Visual Studio), I set the entire Poco file structure aside, and unzipped a fresh copy. The OpenSSL install is also fresh and untouched. The x64 build produces the identical error...
There is a hidden readme file https://github.com/pocoproject/poco/blob/master/README. I'm quoting:
Through the Poco/Crypto/Crypto.h and Poco/Net/NetSSL.h header files,
Visual C++ will automatically link the libcrypto.lib and libssl.lib
libraries. If your OpenSSL libraries are named differently, compile
with the macro POCO_EXTERNAL_OPENSSL defined and edit the project
files accordingly.
You can try to re-compile with the POCO_EXTERNAL_OPENSSL macro set accordingly (see Foundation/include/Poco/Config.h). (source)
Or what I did. Edit the file Crypto/include/Poco/Crypto/Crypto.h, remove all if-else logic around pragmas and leave only libraries that use have:
#pragma comment(lib, "libcrypto64md.lib")
#pragma comment(lib, "libssl64md.lib")
This is not a direct answer - it is an alternative build path that has been confirmed to produce viable DLLs. Try:
Start command line tool from Visual Studio
Invoke vcvars32.bat or vcvars64.bat to ensure environment is correct for Win32 or x64 build.
I found these scripts in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build
Ensure the Poco buildwin.cmd script is configured to specify location of OpenSSL include and lib sub-folders
you will likely have to modify the script between builds if building both 32- and 64-bit builds since openSSL-Win32 and openSSL-Win64 are separate installations
specify include and lib paths for other components the same way (e.g. MySQL and/or PostgreSQL, etc)
Edit the Poco "components" file to eliminate any components not required that will stop build
Invoke buildwin, e.g.:
buildwin 160 shared both Win32 samples notests
buildwin 160 shared both x64 samples notests
I'm trying to build a solution from command line. This involves 3 steps:
nuget install
nuget restore
msbuild
I am using a NuGet.Config files that specifies where the nuget packages are cached to, and also where the restored packages are added.
The command nuget restore does not work, nor does it provide a helpful error message other than 'the solution can't be built'. Another answer on StackOverflow helpfully recommended to run the msbuild command and see what the error is.
It would seem that files installed via nuget are not found during msbuild (or apparently nuget restore). This is the log from msbuild for every single assembly other than what is found in GAC:
Primary reference "NTRPRS.NLog.Slack".
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "NTRPRS.NLog.Slack". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [C:\Avesta\Services\Dashboard\src\Avesta.DashboardService.csproj]
For SearchPath "{HintPathFromItem}".
Considered "..\..\..\..\AppData\Roaming\NuGet\packages\NTRPRS.NLog.Slack.5.0.4\lib\net45\NTRPRS.NLog.Slack.dll", but it didn't exist.
For SearchPath "{TargetFrameworkDirectory}".
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\NTRPRS.NLog.Slack.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\NTRPRS.NLog.Slack.exe", but it didn't exist.
For SearchPath "{Registry:Software\Microsoft\.NETFramework,v4.5,AssemblyFoldersEx}".
Considered AssemblyFoldersEx locations.
For SearchPath "{AssemblyFolders}".
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\NTRPRS.NLog.Slack.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\130\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\130\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\130\NTRPRS.NLog.Slack.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies\NTRPRS.NLog.Slack.exe", but it didn't exist.
Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\NTRPRS.NLog.Slack.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\NTRPRS.NLog.Slack.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\NTRPRS.NLog.Slack.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\NTRPRS.NLog.Slack.exe", but it didn't exist.
For SearchPath "{GAC}".
Considered "NTRPRS.NLog.Slack", which was not found in the GAC.
For SearchPath "{RawFileName}".
Considered treating "NTRPRS.NLog.Slack" as a file name, but it didn't exist.
For SearchPath "bin\Debug\".
Considered "bin\Debug\NTRPRS.NLog.Slack.winmd", but it didn't exist.
Considered "bin\Debug\NTRPRS.NLog.Slack.dll", but it didn't exist.
Considered "bin\Debug\NTRPRS.NLog.Slack.exe", but it didn't exist.
How can I specify to msbuild where assemblies installed by nuget are? Also.... why is nuget restore failing? The message I get from nuget restore is:
C:\<path>\src>nuget restore
Error parsing solution file at C:\<path>\src\<name>.sln: Exception has been thrown by the target of an invocation.
The project file could not be loaded. Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
The system cannot find the file specified. C:\<path>\src\<name>.sln
using:
MSBuild auto-detection: using msbuild version '15.7.177.53362' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin'.
As far as I can tell, the nuget error output is completely nonsensical. The absolute path C:\<path>\src\<name>.sln absolutely does exist.
This is a problem that only surfaced after 15.7.0 of Visual Studio / MSBuild.
NuGet already has an open issue for this problem: https://github.com/NuGet/Home/issues/6918
The current workaround is to install .NET 4.7.1 until the problem is fixed, because that will install the missing library in the Global Assembly Cache.
Like in this question WebRTC not building for Windows, I can't build WebRTC on a Windows 7 64-bit with VS 2015 but the issue is different.
The fetch and gclient sync go well without error. But when I run the gn gen out/WebRTC, then I get the below error
ERROR at //third_party/protobuf/proto_library.gni:229:15: File is not inside out
put directory.
outputs = get_path_info(protogens, "abspath")
^---------------------------------
The given file should be in the output directory. Normally you would specify
"$target_out_dir/foo" or "$target_gen_dir/foo". I interpreted this as
"//out/Default/gen/webrtc/rtc_tools/event_log_visualizer/chart.pb.h".
See //webrtc/rtc_tools/BUILD.gn:184:3: whence it was called.
proto_library("chart_proto") {
^-----------------------------
See //BUILD.gn:16:5: which caused the file to be included.
"//webrtc/rtc_tools",
^-------------------
Traceback (most recent call last):
File "D:/temp/webrtc-checkout/src/build/vs_toolchain.py", line 459, in <module>
sys.exit(main())
File "D:/temp/webrtc-checkout/src/build/vs_toolchain.py", line 455, in main
return commands[sys.argv[1]](*sys.argv[2:])
File "D:/temp/webrtc-checkout/src/build/vs_toolchain.py", line 431, in GetTool
chainDir
win_sdk_dir = SetEnvironmentAndGetSDKDir()
File "D:/temp/webrtc-checkout/src/build/vs_toolchain.py", line 424, in SetEnvi
ronmentAndGetSDKDir
return NormalizePath(os.environ['WINDOWSSDKDIR'])
File "D:\temp\depot_tools\win_tools-2_7_6_bin\python\bin\lib\os.py", line 423,
in __getitem__
return self.data[key.upper()]
KeyError: 'WINDOWSSDKDIR'
I tried to add the variables mentioned in the above question but it didn't helped.
Any help would be greatly appreciated.
You need set LIB and INCLUDE in envirnment variables (windows sdk).
And set PATH to the correct version of python (I think that 2.7.6) too.
So your envirnment variables should be:
LIB=C:\Program Files (x86)\Windows Kits\10\Lib\10.0.15063.0\ucrt\x64;
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.15063.0\um\x64
INCLUDE=C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\shared;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\ucrt;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\winrt
PATH=C:\src\depot_tools\python276_bin\
Please mark if it worked
libwebrtc
I'm using libwebrtc from https://github.com/cloudwebrtc/libwebrtc-build where that compile is wrapped inside a CMake custom call and I tried to modify LIB/INCLUDE but you probably refer to the Visual Studio IDE variables (which the command line does not have or where it does not work as I expected it).
My conservative solution now is to print this message before the libwebrtc compile:
if(NOT EXISTS "C:/Program Files (x86)/Windows Kits/10/Redist/ucrt")
message("============================== C:/Program Files (x86)/Windows Kits/10/Redist/ucrt missing ==========================")
message("C:/Program Files (x86)/Windows Kits/10/Redist/ucrt can not be found")
message(" normally it contains files like /DLLs/x64/ucrtbase.dll and is required for libwebrtc to build")
message(FATAL_ERROR "Please copy the directory C:/Program Files (x86)/Windows Kits/10/Redist/10.0.18362.0/ucrt into C:/Program Files (x86)/Windows Kits/10/Redist/")
endif(NOT EXISTS "C:/Program Files (x86)/Windows Kits/10/Redist/ucrt")
Another would be to patch https://github.com/nareix/webrtc.build/blob/69e87f529e935111b2b8c774ce283366fa2157d0/vs_toolchain.py#L212 to (pseudocode):
ucrt_dll_dirs = os.path.join("C:/Program Files (x86)/Windows Kits/10/Redist/10.0.18362.0/", 'DLLs', target_cpu)
But since that python code is checked out from the libwebrtc and potentially overridden periodically I go with the manual solution.
xcopy (manual copy of files)
xcopy /Y /E /I "c:\Program Files (x86)\Windows Kits\10\Redist\10.0.18362.0\ucrt" "c:\Program Files (x86)\Windows Kits\10\Redist\
alternate discussions
All solutions proposed in https://bugs.chromium.org/p/webrtc/issues/detail?id=7677#c24 also failed for me.
wish
I just wish that the python devs would have spent this another environment variable where we could pass in the directory to look into. Or even better, why did Microsoft create such a crappy infrastructure in the first place -> on UNIX one could use a concept as 'pkg-config' for custom library detection.
I have an executable which is linked to a DLL library. This DLL is in c:\windows\system32
If I put a second DLL in the same path of the executable, this DLL should be loaded instead of the c:\windows\system32
It is very strange because it works like this for some DLLs and not for other.
I tried to copy all dlls of c:\windows\system32 in my executable path and I see with IDA (module window) that some DLLs are loaded in the executable path and others are still loaded in c:\windows\system32
I have scanned all DLLs content, thinking the path was hard coded, but I just see strings with just dll name.
So my question is: What is the rule applied by windows in order to choose which dll to load if there is multiple versions (in executable path and in c:\windows\system32)
Thanks
I'm trying to run msbuild in Jenkins.
When it reaches the UniTest-Project an error occures:
Project "C:\Program Files (x86)\Jenkins\jobs\***\workspace\***.sln" (1) is building "C:\Program Files (x86)\Jenkins\jobs\***\workspace\***.unitTests\***.unitTests.csproj" (4) on node 0 (default targets).
Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
ResolveAssemblyReferences:
Primary reference "Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL".
Could not find dependent files. Could not load file or assembly 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
For SearchPath "{Registry:Software\Microsoft\.NetFramework,v4.0,AssemblyFoldersEx}".
Considered "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VSTSDB\Microsoft.VisualStudio.QualityTools.UnitTestFramework.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VSTSDB\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\2.0\Runtime\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\2.0\Runtime\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
Considered "C:\Program Files (x86)\MySQL\MySQL Connector Net 6.3.6\Assemblies\v2.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.exe", but it didn't exist.
Considered "C:\Program Files (x86)\MySQL\MySQL Connector Net 6.3.6\Assemblies\v2.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
Considered "C:\Program Files (x86)\MySQL\MySQL Connector Net 6.3.6\Assemblies\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.exe", but it didn't exist.
Considered "C:\Program Files (x86)\MySQL\MySQL Connector Net 6.3.6\Assemblies\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.exe", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.exe", but it didn't exist.
CalculatorServiceTest.cs(1,17): error CS0234: The type or namespace name 'VisualStudio' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)
CalculatorServiceTest.cs(11,10): error CS0246: The type or namespace name 'TestMethod' could not be found (are you missing a using directive or an assembly reference?)
CalculatorServiceTest.cs(11,10): error CS0246: The type or namespace name 'TestMethodAttribute' could not be found (are you missing a using directive or an assembly reference?)
CalculatorServiceTest.cs(24,10): error CS0246: The type or namespace name 'TestMethod' could not be found (are you missing a using directive or an assembly reference?)
CalculatorServiceTest.cs(24,10): error CS0246: The type or namespace name 'TestMethodAttribute' could not be found (are you missing a using directive or an assembly reference?)
CalculatorServiceTest.cs(37,10): error CS0246: The type or namespace name 'TestMethod' could not be found (are you missing a using directive or an assembly reference?)
CalculatorServiceTest.cs(37,10): error CS0246: The type or namespace name 'TestMethodAttribute' could not be found (are you missing a using directive or an assembly reference?)
CalculatorServiceTest.cs(6,6): error CS0246: The type or namespace name 'TestClass' could not be found (are you missing a using directive or an assembly reference?)
CalculatorServiceTest.cs(6,6): error CS0246: The type or namespace name 'TestClassAttribute' could not be found (are you missing a using directive or an assembly reference?)
Done Building Project "C:\Program Files (x86)\Jenkins\jobs\***\workspace\***.unitTests\***.unitTests.csproj" (default targets) -- FAILED.
Done Building Project "C:\Program Files (x86)\Jenkins\jobs\***\workspace\***.sln" (default targets) -- FAILED.
Build FAILED.
Any suggestions what the problem could be? Running ms build from the command works for the solution and without any additional parameters when the project was compiles in VS bevor. After a clean solution the same errors occur. Must be some parameter or reference problem; Line two talks bout v4 and v3.5 problems; but i can't figure out how to solve this.
Greets
Error info directly shows that you use incorrect version of MSBuild
This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Try to rebuild with MSBuild 4.0
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe *.sln /t:rebuild
OR/AND from VS2010 Command Line.
I had a similar problem which seemed to be caused by running Jenkins as a service under the SYSTEM account. Somehow cmd.exe was not referencing all the necessary environment variables to be able to find my NUnit assemblies.
If you're running Jenkins as a service, try setting it to run as your user account and see if that helps.
Im building from the default windows cmd using:
C:...\MSBuild.exe *.sln
The solution-projects are all 3.5; only the Unit-Test Project is 4.0 (as you can't change this)
I just mentioned, that building it that way works, when i build it first with VS and don't deleted (clean solution) the binaries. Never mind.
How do i have to use msbuild from cmd to build a *.sln including unittests?