The top line of my code 'module Title' is giving me a dual warning "The search directory 'C:\z3-4.3.0-x64\bin\' could not be found". One for my .fs (f#) file and one for some FSC file. I believe FSC is or has something to do with the main project file.
Although I suppose I could try placing a z3 library folder in that specific location, I really don't want to. I have to localize this project for portability. I'm not sure if that file path string is hardcoded or if it was generated from asking my system where things like that are supposed to be installed.
When I search for things like "The search directory" + "could not be found" + visual + studio, I don't get any interesting results.
This path is not hardcoded in Z3 or in F#. It's possible that someone added it to the system settings, e.g., the PATH variable, but that wouldn't produce this warning. By the folder name, I would conjecture that somebody downloaded the Z3 distribution (.zip) and unzipped it in C:.
It can really only be something that's left over from previous projects, e.g., either in the project settings or in the global Visual Studio settings. It seems F# is searching for a module and while doing that, it finds that the directory doesn't exist, which is only a warning because finally all modules can be found elsewhere anyways.
Regarding 'FSC', that's the name of the F# compiler, quite possible that this name pops up in some error messages etc.
Related
I want to build a DLL version of libjpeg 9b. According to the document here, it seems that we need to add a preprocessor __declspec(dllexport) or __declspec(dllimport) before the declaration of each function to be exported, in addition to setting the Configuration Type to "Dynamic Library (.dll)". But this is not an easy job because there are so many functions in libjpeg. So, is there any short-cut or work-around to build a DLL libjpeg without or with little modification of the jpeglib.h? Is there any DLL-ready source of libjpeg 9b available? I am using Visual Studio 2015 on Windows 7 64bit. Thanks for your answer.
PS: I downloaded the source of libjpeg 9b from http://www.ijg.org/files/. Is this the official place to download it? I ask because the beginning bytes of .vcxproj (originally .v10) files seems invalid (C2 8B C2 AF C2 A8) so Visual Studio is unable to open it.
Published builds (static / dynamic) on [GitHub]: CristiFati/Prebuilt-Binaries - (master) Prebuilt-Binaries/LibJPEG.
Like almost all of the nowadays software, LibJPEG is also hosted on [GitHub]: winlibs/libjpeg - libjpeg-9b. I downloaded it from both places, did a comparison and only few minor differences (out of which none in the source code) popped up. I'm going to explain on the GitHub version. Unfortunately, there is no walkthrough on this, so I had to look inside some of the files in order to figure out what has to be done. Here's a list of steps:
1. Prepare the ground
1st thing is to extract the compressed (.zip / .tar.gz) file content into a folder (and have a Cmd console opened there). That folder contains a bunch of files. The 1st one that we need is makefile.vc. As it name suggests, it's a Makefile that consists of a series of rules/instructions used in general to build stuff.
As a remark, I'm using VStudio (Community) 2015 (14) for this task (but there should be no differences for newer versions).
The tool that deals with Makefiles is NMake ([MS.Docs]: NMAKE reference). We need to call it against that file. NMake is located in "${VSTUDIO_INSTALL_DIR}\VC\bin\nmake.exe" (the (Nix style) env var doesn't really exist, it's just a path placeholder); typically that is "%SystemDrive%\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake.exe" (e.g. on my machine it's "C:\Install\x86\Microsoft\Visual Studio Community\2015\VC\bin\nmake.exe").
Note that when dealing with VStudio command line tools, it's better to either:
Use VCVarsAll (that's a (batch) tool that sets some env vars like %PATH%, %INCLUDE%, %LIB%, ...), so all the VStudio tools are available without their full path. But since it's also located in "%VSTUDIO_INSTALL_DIR%\VC\vcvarsall.bat" (check [SO]: Linking to CRT (unresolved external symbol WinMainCRTStartup) (#CristiFati's answer) for more details), it doesn't worth the effort to locate / call it
Use VS2015 Tools Command Prompt from Start Menu (which basically calls VCVarsAll)
[MS.Docs]: Building on the Command Line contains more details on this topic
Now that we know where NMake is located, let's run:
"${VSTUDIO_INSTALL_DIR}\VC\bin\nmake.exe" /f makefile.vc setup-v10
(don't forget to enclose NMake's path in DblQuotes("), especially if it contains SPACEs).
If running into issues, Google will probably yield solutions:
One very likely to be encountered: fatal error U1052: file 'win32.mak' not found - check [SO]: Visual Studio NMake build fails with: fatal error U1052: file 'win32.mak' not found (#CristiFati's answer)
setup-v10 is a Makefile target, which simply renames some of the files in the folder (frankly, I don't know why the files aren't like already renamed in the 1st place).
After running the command in the folder, there should be 2 VStudio solution files:
jpeg.sln - which contains one project:
jpeg.vcxproj - this is the project responsible of building the lib
apps.sln - which contains a bunch of projects (which I don't know/care what they do):
djpeg.vcxproj - this is the only one that I'm going to mention, since I'll be using it to test the built lib
2. Build the jpeg library
The 1st thing to notice is that the solution / project files generated in the previous section are for VStudio 2010. But that's not a problem, since VStudio 2015 is able to handle them (when loading them, it will do all the necessary conversions to bring them up to date).
Opening jpeg.sln, will reveal some (unpleasant) stuff about the solution (and project):
It only has Win32 (32bit or x86) platform
It only has Release configuration
As you already mentioned, it builds a static library
Anyway, the solution should build OOTB. After completion, you'd notice a Release folder which should contain (besides a bunch of intermediary - .obj files), a 4+ MB jpeg.lib file which is the static .lib. Knowing that the code (and project related files) is OK, let's move on to the next step.
2.1 Build the jpeg .dll
In order to avoid breaking existing functionality, we should create a new configuration (note that the process of creating a new platform for your project is (almost) the same):
From menu, choose Build -> Configuration Manager...
In the dialog box that popped, up click on the Release combo box and select < New...>
In the New Solution Configuration dialog box, select a name for the new configuration: I chose Release-DLL (and from now on I'm going to rely on this name)
Make sure to select Release in the Copy settings from combo-box
Check Create new project configurations
After pressing OK, the new the Release-DLL configuration will be identical to Release. Next step is to do the necessary changes to it, in order to achieve our goal. RClick on the jpeg project in the Solution Explorer (in the left side of VStudio window), and choose Properties:
In the image above, there's the jpeg project settings window, showing how they should look like at the end. I highlighted (using colors) different points of interest:
Blue: the Platform / Configuration pair:
That is being modified (in the topmost dialog box)
Active (in the VStudio main window in the back)
When modifying some Platform / Configuration settings make sure that it's the active one (the data in the blue rectangles is identical), otherwise you'd bang your head against the walls and waste time trying to figure out why something that seems correct, doesn't work as expected. On my opinion, when this dialog box pops up, it should have the active values, but that's not always the case.
Red: items that should be modified (or at least require attention):
Configuration Type should obviously be Dynamic Library (.dll)
Platform Toolset should be Visual Studio 2015 (I'm mentioning this, since it happened to open a VStudio 2010 project with VStudio2015, and it kept the old toolset, and continued to build with it, but that's only if you have both versions installed)
Green: items recommended to be modified. Those are only folders. Notice the $(Platform) variable (that I use as a good practice), which comes in handy when building for more than 1 platform (e.g. Win32 and x64)
Save All and build. After the build succeeds, a new folder Win32-Release-DLL will appear, and like the previous one, it will contain a bunch of files plus jpeg.dll. One might think that it's done, but it's not quite so. All the code is compiled/built in the .dll, but it's not exported, so the .dll is pretty much unusable. You can check many of .dll (or .exe) properties opening it with Dependency Walker (or newer [GitHub]: lucasg/Dependencies). You can look at the screenshots from [SO]: Excel VBA, Can't Find DLL Entry Point from a DLL file (#CristiFati's answer) - in our case the export area will be empty.
One final note: If you think that in the future you'll need to build for other platforms (x64, or even ARM), and also you'll need to do some debugging (add a Debug configuration), add the Debug configuration under Win32 platform first, and only then create the new platform from Win32, otherwise you'll need to add the Debug configuration for every platform created before adding the Debug configuration to Win32.
2.2 Export data from the .dll
Just as a note: besides the __declspec(dllexport) approach, there are 2 more (when dealing with exports from Win .dlls):
Pass the export list as arguments to the linker ([MS.Docs]: /EXPORT (Exports a Function))
Enumerate them in [MS.Docs]: Module-Definition Files
But, since we don't know the code and there might be many symbols to export, neither one of the 3 is scalable (they would probably require lots of research / work). Anyway, we'll stick to the original approach:
Save the following piece of code:
#pragma once
#if defined(_WIN32)
# if defined(LIBJPEG_STATIC)
# define LIBJPEG_EXPORT_API
# else
# if defined(LIBJPEG_EXPORTS)
# define LIBJPEG_EXPORT_API __declspec(dllexport)
# else
# define LIBJPEG_EXPORT_API __declspec(dllimport)
# endif
# endif
#else
# define LIBJPEG_EXPORT_API
#endif
in a file called jexport.h in the libjpeg source folder. This is a pretty standard header file that deals with .dll exports.
Next, add it to the project: in Solution Explorer, RClick on Header Files -> Add -> Existing Item...
Make use of the new file
--- jmorecfg.h.orig 2016-03-30 09:38:56.000000000 +0300
+++ jmorecfg.h 2017-06-09 21:04:33.762535400 +0300
## -30,6 +30,8 ##
* in all cases (see below).
*/
+#include "jexport.h"
+
#define BITS_IN_JSAMPLE 8 /* use 8, 9, 10, 11, or 12 */
## -245,7 +247,8 ##
/* a function referenced thru EXTERNs: */
#define GLOBAL(type) type
/* a reference to a GLOBAL function: */
-#define EXTERN(type) extern type
+
+#define EXTERN(type) extern LIBJPEG_EXPORT_API type
/* This macro is used to declare a "method", that is, a function pointer.
The above is a diff. See [SO]: Run/Debug a Django application's UnitTests from the mouse right click context menu in PyCharm Community Edition? (#CristiFati's answer) (Patching utrunner section) for how to apply patches on Win (basically, every line that starts with one "+" sign goes in, and every line that starts with one "-" sign goes out). But, since the changes are trivial, they can also be done manually. The file that needs to be changed, is jmorecfg.h (2 things are required):
Include the new file at the beginning (#include "jexport.h")
Modify line 251 (replace #define EXTERN(type) extern type by #define EXTERN(type) extern LIBJPEG_EXPORT_API type)
I consider this step some kind of a workaround (gainarie), but as I stated, the "real thing" would simply require too much work (and time).
Tell the compiler to take our changes into account
Edit the project settings (again be careful with Platform / Configuration), select Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions and replace the old value (in my case: WIN32;NDEBUG;_LIB;_CRT_SECURE_NO_WARNINGS) to WIN32;LIBJPEG_EXPORTS;_CRT_SECURE_NO_WARNINGS;NDEBUG. What I did was:
Adding LIBJPEG_EXPORTS
Removing _LIB
Some shifting
[MS.Docs]: /D (Preprocessor Definitions) might contain some useful info.
As a side note, after the above changes, the original (or "normal") behavior (Release configuration) will not be OK (it will build with a bunch of warnings, but that's not correct technically). That is because I didn't want to rely on the _LIB macro to differentiate between the static / dynamic library build. To straighten things out, add LIBJPEG_STATIC in the Preprocessor Definitions for Release configuration (following the same procedure as above).
Save All and build. After the build succeeds, the jpeg.dll is overwritten, and what's more important: a new file jpeg.lib will be created; that tells us that jpeg.dll exports something. You can check it again with Dependency Walker.
3. Test the .dll
This is optional, I did it to be sure that what I did so far, was not in vain
By tests, I only refer to building and running, meaning that I don't do any functional testing (the functions exported from the .dll actually do whatever they're supposed to)
Load the apps.sln solution, preferably in a new VStudio instance. As I said, I only care about the djpeg project.
1st thing to do, is to build it for the existing Release configuration. But, because of the changes done to jpeg library, it won't build OOTB (there will be linker errors). In order to get rid of them, edit its settings, the Preprocessor Definitions (just like in the previous step), and add LIBJPEG_STATIC (don't forget the separator (;)).
The build should be successful and under djpeg\Release folder, there should be a djpeg.exe file. Attempting to run it, will succeed (and this is the only thing I care about).
Build a new executable that uses our .dll:
Just like in jpeg library's case, create a new configuration: Release-DLL (make sure to do all the steps, but don't change it)
There's only one change required: let the linker know where we built our .lib file. Go to project settings, Configuration Properties -> Linker -> Input -> Additional Dependencies: the 1st is Release\jpeg.lib. Obviously, the path is not correct, so we need to replace Release by Win32-Release-DLL (of course you could use VStudio macros (for Platform / Configuration)). Might check [MS.Docs]: .Lib Files as Linker Input.
Save All and build. After the build succeeds, under djpeg\Release-DLL, there should be a djpeg.exe file. Attempting to run it will fail, since it can't find jpeg.dll. Fix that by either copying jpeg.dll to (check [MS.Docs]: Dynamic-Link Library Search Order for the semantics):
The djpeg.exe's folder
One of the folders that's in the %PATH% env var (or the other way around, append the jpeg.dll folder to %PATH%)
Again, you can check the 2 executables with Dependency Walker (but the size difference says enough: the 2nd djpeg.exe is significantly smaller), to see which one depends on the jpeg.dll. Anyway, here's the output on my computer (yes, Dependency Walker can act as a CmdLine as well :) ):
e:\Work\Dev\StackOverflow\q044450813\src\libjpeg-libjpeg-9b>"c:\Install\x86\Depends\Dependency Walker-politist-texan\AllVers\depends.exe" /c /ot:static.txt djpeg\Release\djpeg.exe
e:\Work\Dev\StackOverflow\q044450813\src\libjpeg-libjpeg-9b>"c:\Install\x86\Depends\Dependency Walker-politist-texan\AllVers\depends.exe" /c /ot:dynamic.txt djpeg\Release-DLL\djpeg.exe
e:\Work\Dev\StackOverflow\q044450813\src\libjpeg-libjpeg-9b>type static.txt | findstr -i "jpeg.dll"
e:\Work\Dev\StackOverflow\q044450813\src\libjpeg-libjpeg-9b>type dynamic.txt | findstr -i "jpeg.dll"
[ ] e:\work\dev\stackoverflow\q044450813\src\libjpeg-libjpeg-9b\djpeg\release-dll\JPEG.DLL
[ ] e:\work\dev\stackoverflow\q044450813\src\libjpeg-libjpeg-9b\djpeg\release-dll\JPEG.DLL 2017-06-09 21:16 2017-06-09 21:16 237,056 A 0x00000000 0x0003ECC8 x86 GUI CV,Unknown 0x10000000 Unknown 0x0003E000 Not Loaded N/A N/A 0.0 14.0 6.0 6.0
Update #0
I've also:
Submitted the changes to [GitHub]: winlibs/libjpeg - Win: build libjpeg as a dll (rejected)
Tried to contact JPEG Reference (several times), but the form froze after hitting SEND (left it even overnight with no luck)
I'm trying to build a solution that has three VB projects; one that I'm working on, and two others that have interdependencies (although one says "unavailable").
In trying to compile, I get regarding the ancillary project, "Unable to find source file 'J:\DSDPAGE_T.xsl' for file 'DSDPAGE_T.xsl', located in '[TARGETDIR]', the file may be absent or locked."
J? I searched the solution to see if "J:" is hardcoded anywhere, and it's not, so...?!?
The "missing" files are right there n the project! Why is it looking in J? If that is hardcoded somewhere, why doesn't 2-clicking the err msg take me to the spot? When I do, a "File System " tab appears with two panes. On the left:
File System on Target Machine
Application Folder
System Folder
User's Desktop
User's Programs Menu
...and on the right pane, a listing of the files in that project (the same ones I see in Solution Explorer), many of whom are the subject of err msgs that they cannot be found...?!?
Is this a "VB thing" (I've never worked with VB before) or...?!?
Maybe I can create a J drive and put those files the compiler is wearing blinders about in there just so it will compile - it's not that project I need to work on anyway, I just need to let the solution compile, so I can update the other project.
UPDATE
Looking at one of these files that is visible in the project, but for which the project exhibits acute myopia, its "SourcePath" property does say "J:\DSDPAGE_T.xsl" but that property is readonly/grayed out.
UPDATE 2
In response to user2701753:
I know what you're talking about; I'm used to having these in C# projects; but in this case, there are no References folders. There is only:
Solution 'HDP' (2 projects)
HDP [project#1]
ReportFormats [folder]
[a bunch of .xsl files]
[a bunch of .vb files]
HDPSetup [project#2] <-- the problem child
DetectedDependencies [folder]
[various files: .dll, .xsl, .exe, .chi, .chm, .mdb, .bmp, .ico]
The "Detected Dependencies" folder (which I thought was maybe the VB version of References) is apparently empty - 2-clicking it does nothing; it doesn't expand or open up.
UPDATE 3
Here is perhaps a good clue: When I look at the project files in Windows Explorer, many of the files that display in Visual Studio are not seen there! For example, C:\Project\ccr\Handheld\Development\Development\HDP\HDP\HDPSetup only has this:
Debug [folder] <- empty
Release [folder] <- empty
HDPSetup.vdproj
HDPSetup.vdproj.vspscc
ccr.bmp
ccr.ico
According to VS, I would expect to see those files that it complains about being on the (nonexistent) J: drive.
UPDATE 4
This is related to the issue above.
To recap the gist: I am trying to port/upgrade a VB.NET (.NET2/VS 2003) solution to .NET4/VS2010.
The solution is comprised of three projects; the Setup project was wreaking more mayhem and malevolence than a marauding crash of rhinoceropuses (it was thought to be on drive J, apparently), and I don't need to do anything to that project, so I removed it from the solution.
That removal reduced my error count from 35 to 14.
However, the remaining errs seem related to the "other" project. There are now two; I'll call them HDP and HHTConvert (because those are their names, and my current employer doesn't seem to be as paranoid about divulging any info that would identify the company or project as my previous one was).
Although the Project Dependencies allows me to set one as dependent on the other, no matter which way I set it, it fails:
0) Both depending on each other - disallowed, circular jerk tailchasing considered bad juju
1) HDP depending on HHTConvert: Type 'HHTConvert.HHTConverter' is not defined.
2) HHTConvert depending on HDP: ""
3) Neither depending on the other:""
So it doesn't matter what I do, the same err msg appears. The line the err points to is:
Public hhtConvertThread As HHTConvert.HHTConverter
What do I have to do to introduce the HHTConvert project to the HDP project? It would seem them being in the same solution - especially when one "depends" on the other - would be enough. HHTConverter is apparently not very dependable.
UPDATE 5
Correction/amendment to my original statement: "I'm trying to build a solution that has three VB projects"
Actually, I successfully removed one project, so it is two projects, and one is C# (the "main" one, HDP, is VB).
Could that (the C#/VB "mismatch) cause the two projects to look askance upon each other, akin to the renowned Star-bellied Sneeches and the "plain vanilla" Sneeches? (I consider the plain ones to correspond to VB).
UPDATE 6
So I've got it compiling now (see my answers), but I'm getting a subsequent (runtime) error, namley: "Unable to load DLL 'cdbmenu1.dll': The specified module could not be found."
And sure enough, one of the VB files does references a DLL with that rather bland name several times, with lines such as:
Declare Sub GetLastMenu1Error Lib "cdbmenu1.dll" (ByVal Msg As String, ByVal Length As Int32)
So, I searched the local (work) network and found some copies of that DLL. I copied the newest version (2.5 years old) to HDP's bin folder, and tried to run the app. Now I get, "An attempt was made to load a program with an incorrect format"
Is this the part of the story known as "DLL Purgatory" or a rendition of "DLL Perdition"
(geschweige denn "Extraordinary DLL Rendition")?
Look at the 'References' in the projects in the Solution Explorer, these have a 'Full Path' if that's wrong drop the reference and readd it.
In the visual studio setup project have you added "active content" from VB project? Open your VB project file in a notepad, check the different files included in your project file, your setup project will try to include all those files as a part of your MSI. So open the project file and you should see the J drive there.
All those files can be taken out from the project and then re added.
I solved it: I had to add the .DLL from the C# project to the VB project's References. Once I did so, all errors disappeared. Why that wasn't already there, I have no clue.
I created a new VB.net windows applications project and added a reference to my utilities project like I have done many times before. When I start coding, the editor will find the utility namespace without difficulty but when I build I get "Type My.Utils.Data is not defined".
I've compared my project to my other projects and can't find a difference.
When I try to debug, I get a dialog saying "Visual Studio cannot start debugging because the debug target "C:.....\myproject.exe" is missing
You need to make sure that the consuming project is targeting a .NET Framework version which is equal to or higher than the other project that it is referencing. If the referenced project is targeting a higher version of the framework, Visual Studio will not give you a useful message like, "Wrong Framework Version". Instead, it gives you a very confusing error about the assembly being missing, even though it's there.
I ran into this error and had a more unusual root cause. I'll add it here because someone may experience the same. (I don't expect this to be the "normal" cause of this error.) Anyway, I created a service reference and I removed the text "Reference" from the name of it and called it "ServiceName" rather than "ServiceNameReference. Apparently that created a naming conflict that blew up the reference.vb file.
I have a Labview project containing several classes and a few VIs associated with each class.
The project and all the associated files are contained in a single directory.
When I duplicate (or even rename !) the project dir, I am able to load it but Labview warns me that several "Conflicts" exist. I wasn't able to resolve them by myself.
I understand that Labview can get confused if it loads a few identically-named VIs from another folder ; but why do problems appear even when renaming the folder ?
Isn't there a way to tell Labview to look first in the relative path and load in priority whatever it finds there, without looking elsewhere ?
Why is an operation that is so easy in text-based languages (recursive copy of a folder) so complicated and troublesome in Labview ?
I also tried duplicating the whole hierarchy through "File -> Save", but this also produced conflicts..
Renaming or copying a whole project usually work, since project's VIs are specified by paths relative to the project file.
However there are cases where other VIs referencing VIs inside the project folder. In this case you get conflicts, unless you save the project to another location using "Save as" dialog and specify "Duplicate .lvproj file and contents"
My solution is that I don't think there is a solution. I have the same problem and I have even talked to NI about it with no help.
I did find that, even when the list of conflicts is large, you only need to resolve a few conflicts before LabVIEW figures out the rest. Also don't panic if LabVIEW won't let you resolve a particular conflict. Just move on to the next conflict that you can resolve. As I said before, in time, LabVIEW will figure out the rest.
I have a visual studio solution written using VB.net.
The solution contains 4 projects.
A GUI
A Service
A Settings library
A WiX Setup project
Here's how it used to work.
Last week, I had no shared settings library, and all was fine. But, because both the GUI and the Service contained an identical class named ConfigXML.vb (for serializing and deserializing settings), which I was regularly making changes to and copying and pasting between projects, I decided to extract the class into a library project of it's own (3 above).
This week, nothing works!
I added project references to 1. and 2. and things do work the same as they ever did. When I "start debugging" I can see and use the GUI as normal.
However, the problem I have is that when I create and install a new Setup of the solution, both the GUI and the Service fail to start.
I presume that the problem is the settings library is no longer where it was expected to be / hasn't been registered properly, needs to be placed in a directory by the Setup.msi or something similar.
This is my first time doing something like this, so I expect it's an obvious fix that I need.
I gather from the name of that class "...XML.vb" that there is an XML file that lives along side this class on disc. If there is such a file, then you need to add that file to the project and then right click on it go to "Properties" and set the "Copy to Output Directory" to "Copy if Newer"