Page 1 of 2
Native Resource compiler
Posted: Thu Nov 23, 2017 9:27 am
by Serggio
I'm using X# general public release Anjou 1.1 in VS 2015.
I've created a VO-style form in a project. And I get such an error message while building it:
C:Program Files (x86)MSBuildXSharpXSharp.targets(148,5): error : Cannot find the Native Resource compiler in the XSharp Bin folder
I have X# installed at D:XSharp
And I have rc.exe and rcdll.dll there along with other files.
Native Resource compiler
Posted: Thu Nov 23, 2017 10:31 am
by robert
Sergio,
Did you use the installer to install the product to D:XSharp ?
It looks like a registry key is missing on your computer, or pointing to the wrong folder.
Can you check if you have the registry key:
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeXSharpBVXSharp
And a string value XSharpPath inside that key.
This should point to the root folder of your XSharp installation
Btw:
Please explain to me why did you choose to install outside of Program Files ?
Even the best product can have problems in the installer that will most likely only be visible if you start changing default settingns.
Robert
Native Resource compiler
Posted: Thu Nov 23, 2017 11:57 am
by wriedmann
Hi Robert,
PMFJI
since I have installed the first version of X# on my machine, it is installed in c:xsharpcompiler, and XIDE is installed in c:xsharpxide.
So I don't have to mess when updating from a zip, or to save/restore compiler versions.
Wolfgang
Native Resource compiler
Posted: Thu Nov 23, 2017 1:15 pm
by Serggio
Robert van der Hulst wrote:
Can you check if you have the registry key:
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeXSharpBVXSharp
And a string value XSharpPath inside that key.
Yes, there is and XSharpPath equals to: D:XSharp, which is correct.
Should I reinstall X# to Program Files and would that help with my issue?
Native Resource compiler
Posted: Thu Nov 23, 2017 1:35 pm
by robert
Serggio,
For now installing into the default "C:Program Files (x86)XSharp" location would be the easiest solution.
I did find a problem in our build support DLL and we will release a fix very soon.
Robert
Native Resource compiler
Posted: Thu Nov 23, 2017 1:42 pm
by ArneOrtlinghaus
I have done similar to Wolfgang: Installing into another directory apart from the proposed directory. And I get the same errors as him.
My reasons for not choosing the program files directory are based on experience. Especially since Windows Vista the program directories do not have standard write Access. So many programs fail when installing them into the programs directory because they want to write something into their own directories: Updates, Packages loaded during initialization, Settings files. Some months ago I had again such a program, used by many people: When installing into the proposed Program files directory, I received strange errors because the program wanted to download additional packages. When reinstalling into a separate directory everything was ok.
Additionally some programs get problems with spaces in the directory and with the older versions with directory names displayed in German, but internally in English gave also many strange effects.
Arne Ortlinghaus
Native Resource compiler
Posted: Thu Nov 23, 2017 2:08 pm
by robert
Arne, Wolfgang,
Fair enough.
However we do not write to the PF files subfolder. And our examples are installed in the public documents folder.
By installing to a different location you are introducing a "challenge" for installer and other components with the risk that something is broken.
For now if you create a XSharpBin folder inside Program Files (x86) and copy rc.exe and rcdll.dll there you should be fine.
Robert
Native Resource compiler
Posted: Thu Nov 23, 2017 2:58 pm
by Serggio
Robert van der Hulst wrote:For now if you create a XSharpBin folder inside Program Files (x86) and copy rc.exe and rcdll.dll there you should be fine.
Yes, it works this way. Thank you!
Native Resource compiler
Posted: Thu Nov 23, 2017 2:59 pm
by ArneOrtlinghaus
Thank you.
5 minutes ago Chris sent me a corrected version to test this. I sent the error on Monday and now within 3 work days a solution has been found. That's a good response time. Our customers often must wait longer... : whistle:
Arne
Native Resource compiler
Posted: Thu Nov 23, 2017 7:25 pm
by Chris
Arne, you're welcome and thank you for the very detailed bug report, you know what I am talking about!
Chris