Eclipse - Problem Occurred using actual vs Project directory reference - eclipse

Using Eclipse 2020 with 2 different Projects. Each Project has their own Workspace.
Workspace1/Project1 Run as expected.
Workspace2/Project2 generates the following error indicating an inability to find MyJarFile.jar:
All the Build values are the same, but when comparing the Dependencies between the working and failing environment I noticed the following.
The working environment shows reference to MyJarFile.jar as an actual path reference.
The failing environment shows reference to MyJarFile.jar as a reference via the Project Name.
The strange thing is when I first Add MyJarFile.jar it shows the actual path name, but after closing and reopening the Dependencies tab, it converts the \MyProject\ reference.
In both scenarios it has been confirmed the file exists.
Also, the addition of the File was done using the dialogbox so that also confirms it exists.
Questions:
1 - Is there a setting which dictates when the actual directory reference is shown and when the \Project\ reference is used?
2 - When the \Project\ reference is used, is there an extra step required so the associated file is actually found?

Related

Doxygen failed to run html help compiler, hhc.exe error HHC5010 when running from folder that has a parent folder that starts with "."

I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.

Robot FrameWork : Issue when parameterizing Resource path in Settings

Robot Framework -I have issue parameterizing the resource path in settings section.Currently I have object repository in a file for my selenium project and saved it as ObjectMap.Robot file. The OR file is placed inside project . My objective is to place the ObjectMap.Robot in remote place to access it.
Currently I have defined the variable in the ConfigVariables.robot
*** Variables ***
${DataFilePath} /Sample/DataFiles/
${OR_PATH} \\\\AIX2UB333/Resources/ObjectMap/
The ${OR_PATH} keep changing And to access OR file in my keyword file, I have set my setting as below.
*** Settings ***
Resource ../Resources/ConfigurationFiles/ConfigVariables.robot
Resource ${OR_PATH}/ObjectMap.robot
Issue : Error is shown as that
The import name/path '${OR_PATH}/ObjectMap.robot' is parameterized.
Some of used parameters cannot be resolved. Use Variable mappings in
red.xml for parameter resolution
Tried adding to red.xml, the error still persist.
The funny thing is that if i run the test case it would run successfully. But the variables used from the objectmap has a red error line in test cases. Every variables has the error
Variable is used, but not defined.
As highlighted by #Bryan Oakley, this is not a Robot Framework problem but a project configuration issue in the Eclipse RED Robot Framework editor.
It seems to me that something in your setup is not correct with respect to the project variable mapping. Please ensure that you have the latest RED by updating your eclipse from the market place or by downloading the latest from the GitHub site. I created a new project and added three files
project:
.
├── red.xml
├── OR
| └── ObjectStore.robot
├── test.robot
└── resource.robot
test.robot
*** Setting ***
Resource resource.robot
Resource ${OR}/ObjectStore.robot
*** Test Cases ***
resource.robot
*** Variable ***
${OR} OR
ObjectStore.robot
[EMPTY]
RED.xml
This then ensures that no error is shown in test.robot
As your object store may change, I'd also advise not to include it in a hard coded configuration reference. Instead use the power of Robot Framework command line variable to add a variable or refer to a variable file to have the flexibility you seek without the need to modify files after fetching them from a source code repository.
I have found a workaround for the situation asked. I inserted a py file which as the code to copy ObjectMap from my remote machine to my local project and method name of this code was used as keyword in robot and applied in Suite setup. In robot I had made a flag as well to run only if the condition satify. The flag is added becos , if any one wants to run the code in the same remote machine that would create various copies of it Object Map in the same machine.
My py code
'def copy_file_from_source_to_destination(self,src,dst):
try:
shutil.copy2(src, dst)
except Exception as e:
return str(e)
return 'Success' '
My robot keyword
'Get Central OR
${DESTINATION}= Catenate ${EXECDIR}${TARGET_OR}
Log ${DESTINATION}
${CALL_STATUS}= Convert To Uppercase ${CALL_STATUS}
Run Keyword If '${CALL_STATUS}'=='YES' Copy File From Source To Destination ${CENTRAL_OR} ${DESTINATION}
A bit late (I must have missed this question on SO),let me sum up above issue. RED does not know the value of variable. Variable can be modified during execution (either by testlogic,suite setups,variable files etc.) so any value assignments from Variable sections cannot be taken by RED to resolve parametrised path. The same applies to system variables such as ${EXECDIR} which can change depending where you start Robot execution and how robot command is constructed.
In another scenario, CI job, based on input parameters (for instance version or type of software to be tested with Robot) modifies variable in paths to use proper library or resource which is valid only for that version or type of software. Without VM mechanism,tester would have to temporary change suites with parametrised imports to direct paths just to be able to use proper imports (real world scenario in Nokia and the reason for VM in red.xml).
Therefore for any imports with variables in path, RED assumes that USER has to specify temporary valid values to be used during edit phase.
This is a reason for Variable Mappings in red.xml - allow to specify values of variables so any paths can be resolved thus allowing to import files.
There is also an entry in RED help (in application and on github):http://nokia.github.io/RED/help/user_guide/working_with_RED/variable_mapping.html
Warning regarding "something is outside Project/Workspace" - a warning which may help to understand why tests are not working when they were checkout from repository on different machine. Any Errors/Warnings can be changed in Windows->Preferences->Robot Framework -> Error/Warnings
Help topic: http://nokia.github.io/RED/help/user_guide/validation/validation_preferences.html
If you have any questions or issues,please create those on issue tracker on RED GitHub project: https://github.com/nokia/RED/issues
RED PM

I've upgraded from Visual Studio 2010 to 2012. Project references to SqlClr projects are looking for my project's dll, but with no file extension

Say I have a SqlClr project called MySqlClrProject, which builds the file MySqlClrProject.dll. I've observed that the Build output file name can be either MySqlClrProject or MySqlClrProject.dll, but either way will produce a file named MySqlClrProject.dll. I also have another project in my solution, called MyClassLibrary, which has a project reference to MySqlClrProject. When I build MyClassLibrary, I'll see this error:
CS0006: Metadata file 'C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject' could not be found
Before that, in the output, I see this:
ResolveAssemblyReferences:
5> Primary reference "MySqlClrProject".
5> Could not find dependent files. Expected file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject" does not exist.
5> Could not find dependent files. Expected file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject" does not exist.
5> Resolved file path is "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject".
5> Reference found at search path location "".
5> Found related file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject.pdb".
5> Found related file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject.xml".
5> The ImageRuntimeVersion for this reference is "".
If I add a post build step that copies MySqlClrProject.dll to MySqlClrProject, all is well. Alternatively, if I reference the dll directly, as opposed to using a project reference, then, again, it works fine. I'd really rather not go either of those routes...
Anyway, has anyone else seen this? Anything I might be doing wrong? I know VS2012 is very new, and they've changed a lot when it comes to SqlClr projects, but I'm wondering if the problem is on my side or Microsoft's.
Thanks.

Why can't I step into or set a breakpoint in my XCode source?

I have several source files (all in one Group) that seem to compile with the project, but I cannot step into them or set any breakpoints within.
These files are newer versions of the same files I had in my project. (I updated the code I am using from a 3rd party). After the update, these newer files seem to compile with the project, but somehow they don't seem to be the ones the linker is putting in my final object (its like its using the older files).
So I can do this:
1. forcibly create a syntax error in one of these file and the compiler complains
I cannot do this:
1. hit a breakpoint in any of these files
2. step into any code in these files from a breakpoint outside
3. add a NSLog statement and see the output
Its like the project file (or something else) has its hand on the old compiled files (hence the project compiles fine and runs) and won't replace with these files.
help!
Sometimes it happens that the new version gets put in some unexpected place and that you indeed have two versions of the file in your project without noticing.
Do a project wide search of some unique content in the old and new files. You should get both files displayed and you can delete the old one.
Are you running in release mode? Breakpoints and NSLog statements don't execute when you build and run in release mode.
Set your Active Build Configuration to Debug.

Unable to sign an imported msi.dll assembly using tlbimp

This seems so trivial, yet I can't get it to work..
I have an msi.dll wrapper (named Interop.WindowsInstaller.dll) which I need to sign. The way to do it is by signing it upon import (this specific case is even documented in MSDN: http://msdn.microsoft.com/en-us/library/zec56a0w.aspx).
BUT - no matter how I do it (w/ or w/o a keyfile, w/ or w/o adding "/delaysign"), the generated assemly's size is always 36,864 bytes and when viewing the DLL's properties there is no "Digital Signatures" tab (needless to say - the DLL is NOT signed).
What am I missing here?? (... HELP!...)
[Note: Eventually I got a hint from Karel Zikmund on this thread, which helped me solve the mystery. I'll paste my reply here - for the greater good].
So, I used the following line to sign-upon-import the assembly:
tlbimp C:\WINDOWS\system32\msi.dll /out:Interop.WindowsInstaller.dll /keyfile:MyKey.snk
I then copied the file to the appropriate location and built the project, but each time the build failed on the following error: Assembly generation failed -- Referenced assembly 'Interop.WindowsInstaller' does not have a strong name.
I thought the problem was with the tlbimp line, but after reading Karel Zikmund's reply and verifying that the DLL is strong-named (using sn -vf Interop.WindowsInstaller) I found out the problem.
Adding a reference to the "Microsoft Windows Installer Object Library" COM object actually planted a code block into the .csproj file.
I didn't realize it, but this block caused the DLL file to be regenerated from scratch upon each time the project was built. The generated file, of course, was not strong-named anymore.
The way I resolved it was to remove the reference to "Microsoft Windows Installer Object Library" from the project, and add a direct file reference to the imported (and already signed) Interop.WindowsInstaller.dll file.