ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

Dear Ada Community 

VisualAda version 1.1.12 has been released 

New Features, fixes include the following 

 - Fix installation issues for Visual Studio 2019
 - Remove ' character from "Brace completion", since its primarily used for attributes (ie 'access, 'address etc..) 

Please feel free to download the free plugin from the following URL 

https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 

Note:

if you have issues with installation, please respond to this post, and I will
endeavour to resolve as soon as possible. In the long term I intend to setup
a specific GitHub project, where issues/improvements can be made for me to action.

Thanks 

Alex 

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Ark Man]

Alex,

This is beyond sick (or slick), take your pick. Opens up a whole range of possibilities.

However :-), I'm unable to build a UWP XAML app. It generates the projects just fine, and the C# project will build, but I'm getting the following error on the Ada project ...

(I'm on VS Pro 2017 v15.9.11, and upgraded to your latest plugin, v1.1.12)

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\VisualAda\BuildSystem\Ada.targets(159,5): error MSB4018: The "CompileTask" task failed unexpectedly.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\VisualAda\BuildSystem\Ada.targets(159,5): error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'System.Reflection.Metadata, Version=1.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Any ideas ? (I have not changed any compiler settings and the GNAT directories were picked up just fine.)

Regards,
Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

UPDATE: For some reason, this error has resolved itself (I SWEAR it!), could be something to do with a VS Community upgraded last year to VS Professional, but who knows.

But am getting a new error from grpconfig at the start of the build:

gprconfig: can't find a native toolchain for language 'ada', runtime 'Winrt_Runtime'
App2019.gpr:4:06: unknown project file: "WinRt.gpr"

WinRt.gpr IS in the share location in my GPS installation, and the bin/ directory is in my PATH.

FYI, this is happening for both VS Pro 2017 and a newly installed VS Comm *2019*.

Regards,
Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Thursday, April 18, 2019 at 6:10:05 AM UTC+10, Greg wrote:
> UPDATE: For some reason, this error has resolved itself (I SWEAR it!), could be something to do with a VS Community upgraded last year to VS Professional, but who knows.
> 
> But am getting a new error from grpconfig at the start of the build:
> 
> gprconfig: can't find a native toolchain for language 'ada', runtime 'Winrt_Runtime'
> App2019.gpr:4:06: unknown project file: "WinRt.gpr"
> 
> WinRt.gpr IS in the share location in my GPS installation, and the bin/ directory is in my PATH.
> 
> FYI, this is happening for both VS Pro 2017 and a newly installed VS Comm *2019*.
> 
> Regards,
> Greg

Hi Greg

Apologies for the delay in responding :-(

You will need to install & build winrt_runtime available from my git repo
https://github.com/Alex-Gamper/Ada-WinRT-Runtime
and the winrt bindings themselves, also available from my git repo
https://github.com/Alex-Gamper/Ada-WinRT

Note that I am making changes to the Winrt_runtime to make it compatible with
the Windows Store certification (aka Windows Application certification Kit, WACK)
I hope to have this finished in the next day or two

A couple of notes:
 - only x64 is currently supported (I haven't had a chance to look at 32bit yet)
 - The build.cmd script should install the RTS correctly

If you have any further issues please let me know

Alex 

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Saturday, April 20, 2019 at 2:23:08 PM UTC+10, alby....@gmail.com wrote:
> On Thursday, April 18, 2019 at 6:10:05 AM UTC+10, Greg wrote:
> > UPDATE: For some reason, this error has resolved itself (I SWEAR it!), could be something to do with a VS Community upgraded last year to VS Professional, but who knows.
> > 
> > But am getting a new error from grpconfig at the start of the build:
> > 
> > gprconfig: can't find a native toolchain for language 'ada', runtime 'Winrt_Runtime'
> > App2019.gpr:4:06: unknown project file: "WinRt.gpr"
> > 
> > WinRt.gpr IS in the share location in my GPS installation, and the bin/ directory is in my PATH.
> > 
> > FYI, this is happening for both VS Pro 2017 and a newly installed VS Comm *2019*.
> > 
> > Regards,
> > Greg
> 
> Hi Greg
> 
> Apologies for the delay in responding :-(
> 
> You will need to install & build winrt_runtime available from my git repo
> https://github.com/Alex-Gamper/Ada-WinRT-Runtime
> and the winrt bindings themselves, also available from my git repo
> https://github.com/Alex-Gamper/Ada-WinRT
> 
> Note that I am making changes to the Winrt_runtime to make it compatible with
> the Windows Store certification (aka Windows Application certification Kit, WACK)
> I hope to have this finished in the next day or two
> 
> A couple of notes:
>  - only x64 is currently supported (I haven't had a chance to look at 32bit yet)
>  - The build.cmd script should install the RTS correctly
> 
> If you have any further issues please let me know
> 
> Alex

Hi Greg

I forgot to mention that you may need to adjust/tweak both the Winrt_runtime.gpr
and the winrt.gpr to fit in with your environment, specifically the variable
"Base_Installation_dir" in both winrt_runtime.gpr and winrt.gpr, as these files
where created manually outside of VisualAda.

I am looking at ways in which gnat/gcc directories/Paths can be dynamically
determined (at build time). In the next release of VisualAda, the dirs. are
dynamically determined when a new project is first created, a step in the right
direction ? But this doesn't help for projects pushed up to Git !

Alex

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

Alex,

Sorry I took so long to get back to you - work, sick family, one thing after another :-(.

Yes, I'm using GNAT Community 2018 64-bit and GNAT is on my PATH.

After setting "git config --global core.autocrlf false", I was able to clone both repos successfully and begin building without goofy line terminator errors.

The WinRT Runtime built successfully according to your notes and seemed to install correctly into "C:/home/greg/apps/GNAT/2018/lib/gcc/x86_64-w64-mingw32/8.3.0/rts-Winrt_Runtime", without any changes to WinRT-Runtime.gpr.

However, when trying to build the WinRT Bindings, I instantly get a "gprconfig: can't find a native toolchain for language 'ada', runtime 'Winrt_Runtime'" error. I know it's a path/dir/install issue of some kind and I'm continuing to fiddle with the env variables/settings you mentioned (I assume it can't find winrt-runtime for some reason). I've even tried setting "for "Runtime_Dir ("Ada")" without luck so far.

I think I'm very close :-), and will let you know. (The payoff is certainly worth the effort.)

Regards,
Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Sunday, April 28, 2019 at 1:19:28 PM UTC+10, Greg wrote:
> Alex,
> 
> Sorry I took so long to get back to you - work, sick family, one thing after another :-(.
> 
> Yes, I'm using GNAT Community 2018 64-bit and GNAT is on my PATH.
> 
> After setting "git config --global core.autocrlf false", I was able to clone both repos successfully and begin building without goofy line terminator errors.
> 
> The WinRT Runtime built successfully according to your notes and seemed to install correctly into "C:/home/greg/apps/GNAT/2018/lib/gcc/x86_64-w64-mingw32/8.3.0/rts-Winrt_Runtime", without any changes to WinRT-Runtime.gpr.
> 
> However, when trying to build the WinRT Bindings, I instantly get a "gprconfig: can't find a native toolchain for language 'ada', runtime 'Winrt_Runtime'" error. I know it's a path/dir/install issue of some kind and I'm continuing to fiddle with the env variables/settings you mentioned (I assume it can't find winrt-runtime for some reason). I've even tried setting "for "Runtime_Dir ("Ada")" without luck so far.
> 
> I think I'm very close :-), and will let you know. (The payoff is certainly worth the effort.)
> 
> Regards,
> Greg

Hi Greg

If you are using GNAT community edition, be aware that gcc/gnat by default will
use a target triplet of x86_64-pc-mingw32 and not *-w64-* and that the version
number will be 7.3.1. So you will need to adjust the GPR files to use these
locations.

You can confirm what gcc/gnat uses by default by running "gnatls -v" from a cmd
prompt. The winrt gpr's need to be inline with gnatls

Also, note that the runtime parameter in winrt.gpr is I believe case sensitive

Alex

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Sunday, April 28, 2019 at 1:57:15 PM UTC+10, alby....@gmail.com wrote:
> On Sunday, April 28, 2019 at 1:19:28 PM UTC+10, Greg wrote:
> > Alex,
> > 
> > Sorry I took so long to get back to you - work, sick family, one thing after another :-(.
> > 
> > Yes, I'm using GNAT Community 2018 64-bit and GNAT is on my PATH.
> > 
> > After setting "git config --global core.autocrlf false", I was able to clone both repos successfully and begin building without goofy line terminator errors.
> > 
> > The WinRT Runtime built successfully according to your notes and seemed to install correctly into "C:/home/greg/apps/GNAT/2018/lib/gcc/x86_64-w64-mingw32/8.3.0/rts-Winrt_Runtime", without any changes to WinRT-Runtime.gpr.
> > 
> > However, when trying to build the WinRT Bindings, I instantly get a "gprconfig: can't find a native toolchain for language 'ada', runtime 'Winrt_Runtime'" error. I know it's a path/dir/install issue of some kind and I'm continuing to fiddle with the env variables/settings you mentioned (I assume it can't find winrt-runtime for some reason). I've even tried setting "for "Runtime_Dir ("Ada")" without luck so far.
> > 
> > I think I'm very close :-), and will let you know. (The payoff is certainly worth the effort.)
> > 
> > Regards,
> > Greg
> 
> Hi Greg
> 
> If you are using GNAT community edition, be aware that gcc/gnat by default will
> use a target triplet of x86_64-pc-mingw32 and not *-w64-* and that the version
> number will be 7.3.1. So you will need to adjust the GPR files to use these
> locations.
> 
> You can confirm what gcc/gnat uses by default by running "gnatls -v" from a cmd
> prompt. The winrt gpr's need to be inline with gnatls
> 
> Also, note that the runtime parameter in winrt.gpr is I believe case sensitive
> 
> Alex

Hi Greg

Also, if you run "gnatls -v --RTS=Winrt_Runtime" after the build and install
of the Winrt Runtime, It will confirm correct installation. Here is the output
from my default MSYS2 environment

C:\>gnatls -v --RTS=Winrt_Runtime

GNATLS 8.3.0
Copyright (C) 1997-2018, Free Software Foundation, Inc.

Source Search Path:
   <Current_Directory>
   C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\adainclude


Object Search Path:
   <Current_Directory>
   C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\adalib


Project Search Path:
   <Current_Directory>
   C:\msys64\mingw64\x86_64-w64-mingw32\Winrt_Runtime\lib\gnat
   C:\msys64\mingw64\x86_64-w64-mingw32\Winrt_Runtime\share\gpr
   C:\msys64\mingw64\x86_64-w64-mingw32\lib\gnat
   C:\msys64\mingw64\x86_64-w64-mingw32\share\gpr
   C:\msys64\mingw64\share\gpr
   C:\msys64\mingw64\lib\gnat


C:\>

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

Hey Alex ... SUCCESS !!! (mostly)

My MSYS environment is set up exactly like yours, and I've been able to build and install the Runtime and Bindings, and verified with gnatls, etc.

Now jumping back to VS2019, I created a new XAML project and I've set the 3 Gnat Root directories in the General Ada section of the project properties to your "for example: C:\msys64......" suggestions for each of those. Those directories do, of course, exist in my environment.

Compilation of the XAML project .adb files is working, but failing at the bind stage with something like this:

1>------ Build started: Project: RD, Configuration: Debug x64 ------
1>Compile
1>   [Ada]          appoverrides.adb
1>   [Ada]          guitask.adb
1>   [Ada]          locatortask.adb
1>   [Ada]          rdxaml.adb
1>Bind
1>   [gprbind]      rd.bexch
1>   [Ada]          rd.ali
1>gprbind: invocation of gnatbind failed
1>gprbuild: unable to bind rd.adb
1>MSBUILD : error MSB4166: Child node "2" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\Dad\AppData\Local\Temp\" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
1>A task was canceled.
1>A task was canceled.


... Can't find anything in that TEMP folder, and know I'm just a config settings or two away. I'll keep plugging away at it and see if something jumps out at me. Thanks for all the help, great stuff !!!

Regards,
Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Tuesday, April 30, 2019 at 4:18:25 AM UTC+10, Greg wrote:
> Hey Alex ... SUCCESS !!! (mostly)
> 
> My MSYS environment is set up exactly like yours, and I've been able to build and install the Runtime and Bindings, and verified with gnatls, etc.
> 
> Now jumping back to VS2019, I created a new XAML project and I've set the 3 Gnat Root directories in the General Ada section of the project properties to your "for example: C:\msys64......" suggestions for each of those. Those directories do, of course, exist in my environment.
> 
> Compilation of the XAML project .adb files is working, but failing at the bind stage with something like this:
> 
> 1>------ Build started: Project: RD, Configuration: Debug x64 ------
> 1>Compile
> 1>   [Ada]          appoverrides.adb
> 1>   [Ada]          guitask.adb
> 1>   [Ada]          locatortask.adb
> 1>   [Ada]          rdxaml.adb
> 1>Bind
> 1>   [gprbind]      rd.bexch
> 1>   [Ada]          rd.ali
> 1>gprbind: invocation of gnatbind failed
> 1>gprbuild: unable to bind rd.adb
> 1>MSBUILD : error MSB4166: Child node "2" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\Dad\AppData\Local\Temp\" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
> 1>A task was canceled.
> 1>A task was canceled.
> 
> 
> ... Can't find anything in that TEMP folder, and know I'm just a config settings or two away. I'll keep plugging away at it and see if something jumps out at me. Thanks for all the help, great stuff !!!
> 
> Regards,
> Greg

Hi Greg

My Build output shows compilation of some additional Ada sources, namely rd.adb
and winmainstartup.adb as shown below. Are these files in your project ?
Note the error in my sample, is because Microsoft insists on a filename with
more than 2 characters (Silly Microsoft).

Could you try building manually outside VS with gprbuild. Below are the steps

1) start a VS x64 native command prompt
2) cd to you project directory, you should have RD.gpr in that directory, if
you named your project "RD"
3) run gprbuild -f -v -p -P RD.gpr

In the meantime I'll continue to try and replicate your issue

------ Rebuild All started: Project: RD, Configuration: Debug x64 ------
Compile
   [Ada]          rd.adb
   [Ada]          appoverrides.adb
   [Ada]          winmainstartup.adb
   [Ada]          guitask.adb
   [Ada]          locatortask.adb
   [Ada]          rdxaml.adb
Bind
   [gprbind]      rd.bexch
   [Ada]          rd.ali
RD.vcxproj -> C:\Users\alexg\source\repos\RD\RD\RD\x64\Debug\RD.exe
C:\Users\alexg\source\repos\RD\RD\RD\x64\Debug\AppxManifest.xml : error APPX0501: Validation error. error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 10, Column 13, Reason: 'RD' violates minLength constraint of '3'. The attribute 'Name' with value 'RD' failed to parse.
Done building project "RD.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

Alex,

1. I think I had canceled a build earlier, which is why we didn't see those two "missing" adb files. 
2. Forgotten that SYSTEM paths come before USER paths in Windows, so added some entries to SYSTEM path for MSYS and rebooted.
3. Created a new XAML app in VS 2019 called "RaceDirector" (which is what "RD" stood for, just got lazy.)
4. In VS project properties, "C:\MSYS64\..." picked up correctly for the 3 "Gnat Root" directories.
5. Consequently, I proceeded to build the solution WITHOUT a change to the project properties.
5. Built "RaceDirectorXaml" fine.
6. Building "RaceDirector" yields this:

1>------ Build started: Project: RaceDirector, Configuration: Debug x64 ------
1>Compile
1>   [Ada]          racedirector.adb
1>   [Ada]          appoverrides.adb
1>   [Ada]          winmainstartup.adb
1>   [Ada]          guitask.adb
1>   [Ada]          locatortask.adb
1>   [Ada]          racedirectorxaml.adb
1>Bind
1>   [gprbind]      racedirector.bexch
1>   [Ada]          racedirector.ali
1>MSBUILD : error MSB4166: Child node "2" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\Dad\AppData\Local\Temp\" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
1>A task was canceled.
1>A task was canceled.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Notice I did NOT get the ...
1>gprbind: invocation of gnatbind failed 
1>gprbuild: unable to bind rd.adb 
... but still a build error. And still cannot find a MSBuild_*.failure.txt in the indicated directory.

NEXT ...

Launched a x64 Native VS2019 command prompt:

gprbuild -f -v -p -P RaceDirector.gpr
==============Error messages for file: C:\home\dad\dev2\RaceDirector\RaceDirector\RaceDirector\RaceDirector.gpr
     4. with "WinRt.gpr";
        >>> unknown project file: "WinRt.gpr"
gprbuild: "RaceDirector.gpr" processing failed

So this has GOT to be a directory/path I'm not setting somewhere.

Onward, SO close :)
Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Wednesday, May 1, 2019 at 6:57:28 AM UTC+10, Greg wrote:
> Alex,
> 
> 1. I think I had canceled a build earlier, which is why we didn't see those two "missing" adb files. 
> 2. Forgotten that SYSTEM paths come before USER paths in Windows, so added some entries to SYSTEM path for MSYS and rebooted.
> 3. Created a new XAML app in VS 2019 called "RaceDirector" (which is what "RD" stood for, just got lazy.)
> 4. In VS project properties, "C:\MSYS64\..." picked up correctly for the 3 "Gnat Root" directories.
> 5. Consequently, I proceeded to build the solution WITHOUT a change to the project properties.
> 5. Built "RaceDirectorXaml" fine.
> 6. Building "RaceDirector" yields this:
> 
> 1>------ Build started: Project: RaceDirector, Configuration: Debug x64 ------
> 1>Compile
> 1>   [Ada]          racedirector.adb
> 1>   [Ada]          appoverrides.adb
> 1>   [Ada]          winmainstartup.adb
> 1>   [Ada]          guitask.adb
> 1>   [Ada]          locatortask.adb
> 1>   [Ada]          racedirectorxaml.adb
> 1>Bind
> 1>   [gprbind]      racedirector.bexch
> 1>   [Ada]          racedirector.ali
> 1>MSBUILD : error MSB4166: Child node "2" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\Dad\AppData\Local\Temp\" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
> 1>A task was canceled.
> 1>A task was canceled.
> ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
> 
> Notice I did NOT get the ...
> 1>gprbind: invocation of gnatbind failed 
> 1>gprbuild: unable to bind rd.adb 
> ... but still a build error. And still cannot find a MSBuild_*.failure.txt in the indicated directory.
> 
> NEXT ...
> 
> Launched a x64 Native VS2019 command prompt:
> 
> gprbuild -f -v -p -P RaceDirector.gpr
> ==============Error messages for file: C:\home\dad\dev2\RaceDirector\RaceDirector\RaceDirector\RaceDirector.gpr
>      4. with "WinRt.gpr";
>         >>> unknown project file: "WinRt.gpr"
> gprbuild: "RaceDirector.gpr" processing failed
> 
> So this has GOT to be a directory/path I'm not setting somewhere.
> 
> Onward, SO close :)
> Greg

Hi Greg

Apologies for the delay in responding! Time zone differences always make it
hard to quickly resolve some issues. Anyway, I have rebuilt my environment to
use GNAT Community edition 2018 (which uses gcc version 7.3, rather than the
MSYS2 environment, which uses gcc 8.3)

I have found some issues with Gnat CE 2018, (not in the compiler itself, But
with the underlying mingw32 runtime library) and in no way is this a
fault of AdaCore or the MSYS2 project, Just my inability to resource my own
time to test this under BOTH environments. :-(

I believe I have a solution working for both environments, But I need some time
to test the changes to the WinRT runtime via the ACATS test suite. Please bear
with me (should/might take a day or so to resolve)

If you are keen to use the MSYS2/mingew64 GCC based environment as an 
alternative, I am happy to help you set this up. Its fairly straight forward
to get up and running on windows, and I can assist (ie post a wiki on my GitHub)
if needed.

Alex

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

Alex,

ABSOLUTELY no worries. I switched over to MSYS2 because that was what you were using. My personal preference is GNAT CE, but either way is fine. No rush at all, I never thought I'd be able to do something like WinRT or UWP/XAML in Ada (and I'm trying to relearn Ada, a lot has changed since I took classes and monkeyed with it in the 80's!).

The reason my project is called "RaceDirector" is because I'm rewriting all of our timing & scoring software (and adding some hardware, like the STM32F769NIH6 microcontroller (embedded Ada!)) for our Soap Box Derby track (if you're curious, http://ghsbd.org). I thought it'd be a cool way to do it.


We're done with our Spring events, and won't start up again until late Summer, early Fall (too !*&@# hot in Texas during the summer.)

Side note: I'm assuming that since these are true Windows Store apps, that they could also run on Xbox, but its been a while since I messed around with that. I'd love to explore that as well (I also occasionally write some small apps for my autistic teenager to help him in a few areas.)

Let me know how I can help, test, maybe add some stuff to the extension (Intellisense ?), whatever.

Regards,
Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Thursday, May 2, 2019 at 2:45:37 AM UTC+10, Greg wrote:
> Alex,
> 
> ABSOLUTELY no worries. I switched over to MSYS2 because that was what you were using. My personal preference is GNAT CE, but either way is fine. No rush at all, I never thought I'd be able to do something like WinRT or UWP/XAML in Ada (and I'm trying to relearn Ada, a lot has changed since I took classes and monkeyed with it in the 80's!).
> 
> The reason my project is called "RaceDirector" is because I'm rewriting all of our timing & scoring software (and adding some hardware, like the STM32F769NIH6 microcontroller (embedded Ada!)) for our Soap Box Derby track (if you're curious, http://ghsbd.org). I thought it'd be a cool way to do it.
> 
> 
> We're done with our Spring events, and won't start up again until late Summer, early Fall (too !*&@# hot in Texas during the summer.)
> 
> Side note: I'm assuming that since these are true Windows Store apps, that they could also run on Xbox, but its been a while since I messed around with that. I'd love to explore that as well (I also occasionally write some small apps for my autistic teenager to help him in a few areas.)
> 
> Let me know how I can help, test, maybe add some stuff to the extension (Intellisense ?), whatever.
> 
> Regards,
> Greg

Hi Greg

Your RaceDirector software sounds like an excellent candidate for the "Make with Ada competition" sponsored/run by AdaCore.
Not sure about Xbox integration, but when I get some spare time I'll look into it.

Now onto your original problem. Firstly some background info, which will help us
in finding the root cause of build failure. The VisualAda extension works as follows.

1) When you create a new project, a .vcxproj is created from a project template supplied by the VisualAda extension

2) This .vcxproj is essentially a C/C++ project, primarily because it has a compile AND link phase/target, unlike C# or VB, and I needed the link target for UWP apps

3) The .vcxproj has additional targets to comply with the normal Ada build procedure (ie compile, BIND and link)

4) The MSBUILD engine is used to co-ordinate the build, and invokes specific
targets that end up calling GPRBUILD with either the -c (compile), -b (bind)
or -l (link) command line options.

5) if building UWP/WinrRT based apps, then the final GPRBUILD link is replaced
by a Microsoft linker command

6) If the project "property Use Microsoft Linker" is set to YES (as is the case for
UWP/WinRT based projects) then their is an intervening step between the BIND and
Microsoft LINK phase which converts the GCC dwarf based debug information into
PDB format, so that you can debug the final app using Visual Studio.

7) Note: An equivalent GPR file (to that of the above .vcxproj) is maintained
and re-generated when ever changes to the .vcxproj file are made.

Ok, with that knowledge in hand, lets try and isolate the build failure with the
following, using a VS x64 native command prompt, since this gives us a bit more
flexibility in running individual phase/targets in the build process.

(note I made some minor changes on GitHub, so you may want to do a git pull for
the winrt-runtime project, But I am not entirely convinced that these changes
ae the root cause) 

a) cd into the directory where your <project>.gpr file exists

b) gprbuild -f -c -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr

   this will only do the compilation phase, and should succeed, NOTE I am using
   the default MSYS2 install directories above in the -aP argument, which just
   tells GPRBUILD additional Project directories

   You should see the usual GPRBUILD compile phase output at this stage

c) gprbuild -f -b -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr

   This will then do the bind phase, and should succeed. If this fails, then
   please re-run, but ADD a -vh flag to the gprbuild cmd (ie gpbuild -vh -f …)
   this will give us some additional diagnostics that we can work with

d) If you got this far great, that means gcc/gnat is fine and we need to dig a
bit further. But now since gcc/gnat is out of the picture we need to use the
MSBUILD to diagnose the rest of the build cycle.

e) msbuild -target:clean

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Friday, May 3, 2019 at 9:53:00 PM UTC+10, alby....@gmail.com wrote:
> On Thursday, May 2, 2019 at 2:45:37 AM UTC+10, Greg wrote:
> > Alex,
> > 
> > ABSOLUTELY no worries. I switched over to MSYS2 because that was what you were using. My personal preference is GNAT CE, but either way is fine. No rush at all, I never thought I'd be able to do something like WinRT or UWP/XAML in Ada (and I'm trying to relearn Ada, a lot has changed since I took classes and monkeyed with it in the 80's!).
> > 
> > The reason my project is called "RaceDirector" is because I'm rewriting all of our timing & scoring software (and adding some hardware, like the STM32F769NIH6 microcontroller (embedded Ada!)) for our Soap Box Derby track (if you're curious, http://ghsbd.org). I thought it'd be a cool way to do it.
> > 
> > 
> > We're done with our Spring events, and won't start up again until late Summer, early Fall (too !*&@# hot in Texas during the summer.)
> > 
> > Side note: I'm assuming that since these are true Windows Store apps, that they could also run on Xbox, but its been a while since I messed around with that. I'd love to explore that as well (I also occasionally write some small apps for my autistic teenager to help him in a few areas.)
> > 
> > Let me know how I can help, test, maybe add some stuff to the extension (Intellisense ?), whatever.
> > 
> > Regards,
> > Greg
> 
> Hi Greg
> 
> Your RaceDirector software sounds like an excellent candidate for the "Make with Ada competition" sponsored/run by AdaCore.
> Not sure about Xbox integration, but when I get some spare time I'll look into it.
> 
> Now onto your original problem. Firstly some background info, which will help us
> in finding the root cause of build failure. The VisualAda extension works as follows.
> 
> 1) When you create a new project, a .vcxproj is created from a project template supplied by the VisualAda extension
> 
> 2) This .vcxproj is essentially a C/C++ project, primarily because it has a compile AND link phase/target, unlike C# or VB, and I needed the link target for UWP apps
> 
> 3) The .vcxproj has additional targets to comply with the normal Ada build procedure (ie compile, BIND and link)
> 
> 4) The MSBUILD engine is used to co-ordinate the build, and invokes specific
> targets that end up calling GPRBUILD with either the -c (compile), -b (bind)
> or -l (link) command line options.
> 
> 5) if building UWP/WinrRT based apps, then the final GPRBUILD link is replaced
> by a Microsoft linker command
> 
> 6) If the project "property Use Microsoft Linker" is set to YES (as is the case for
> UWP/WinRT based projects) then their is an intervening step between the BIND and
> Microsoft LINK phase which converts the GCC dwarf based debug information into
> PDB format, so that you can debug the final app using Visual Studio.
> 
> 7) Note: An equivalent GPR file (to that of the above .vcxproj) is maintained
> and re-generated when ever changes to the .vcxproj file are made.
> 
> Ok, with that knowledge in hand, lets try and isolate the build failure with the
> following, using a VS x64 native command prompt, since this gives us a bit more
> flexibility in running individual phase/targets in the build process.
> 
> (note I made some minor changes on GitHub, so you may want to do a git pull for
> the winrt-runtime project, But I am not entirely convinced that these changes
> ae the root cause) 
> 
> a) cd into the directory where your <project>.gpr file exists
> 
> b) gprbuild -f -c -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr
> 
>    this will only do the compilation phase, and should succeed, NOTE I am using
>    the default MSYS2 install directories above in the -aP argument, which just
>    tells GPRBUILD additional Project directories
> 
>    You should see the usual GPRBUILD compile phase output at this stage
> 
> c) gprbuild -f -b -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr
> 
>    This will then do the bind phase, and should succeed. If this fails, then
>    please re-run, but ADD a -vh flag to the gprbuild cmd (ie gpbuild -vh -f …)
>    this will give us some additional diagnostics that we can work with
> 
> d) If you got this far great, that means gcc/gnat is fine and we need to dig a
> bit further. But now since gcc/gnat is out of the picture we need to use the
> MSBUILD to diagnose the rest of the build cycle.
> 
> e) msbuild -target:clean

Sorry, I submitted this reply before I was ready to post, Anyway Continuing on

   the clean target should work fine (this step is NOT really required, but I
   just want to make sure the expected targets are working as expected.)

f) msbuild -target:build

   this will do a build, and should be the same as the compile/bind phase in
   point a) and b) above and the try and do the steps 5) and 6) mentioned above

g) Please check all /LIBPATH command line options in the LINK target, and report
any unusual errors in using MSBUILD (except that you may see a error regarding
not being able to find MSVCRT.LIB (I believe this is a false positive as I can
build fine using VS)


Thanks

Alex

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Friday, May 3, 2019 at 10:05:50 PM UTC+10, alby....@gmail.com wrote:
> On Friday, May 3, 2019 at 9:53:00 PM UTC+10, alby....@gmail.com wrote:
> > On Thursday, May 2, 2019 at 2:45:37 AM UTC+10, Greg wrote:
> > > Alex,
> > > 
> > > ABSOLUTELY no worries. I switched over to MSYS2 because that was what you were using. My personal preference is GNAT CE, but either way is fine. No rush at all, I never thought I'd be able to do something like WinRT or UWP/XAML in Ada (and I'm trying to relearn Ada, a lot has changed since I took classes and monkeyed with it in the 80's!).
> > > 
> > > The reason my project is called "RaceDirector" is because I'm rewriting all of our timing & scoring software (and adding some hardware, like the STM32F769NIH6 microcontroller (embedded Ada!)) for our Soap Box Derby track (if you're curious, http://ghsbd.org). I thought it'd be a cool way to do it.
> > > 
> > > 
> > > We're done with our Spring events, and won't start up again until late Summer, early Fall (too !*&@# hot in Texas during the summer.)
> > > 
> > > Side note: I'm assuming that since these are true Windows Store apps, that they could also run on Xbox, but its been a while since I messed around with that. I'd love to explore that as well (I also occasionally write some small apps for my autistic teenager to help him in a few areas.)
> > > 
> > > Let me know how I can help, test, maybe add some stuff to the extension (Intellisense ?), whatever.
> > > 
> > > Regards,
> > > Greg
> > 
> > Hi Greg
> > 
> > Your RaceDirector software sounds like an excellent candidate for the "Make with Ada competition" sponsored/run by AdaCore.
> > Not sure about Xbox integration, but when I get some spare time I'll look into it.
> > 
> > Now onto your original problem. Firstly some background info, which will help us
> > in finding the root cause of build failure. The VisualAda extension works as follows.
> > 
> > 1) When you create a new project, a .vcxproj is created from a project template supplied by the VisualAda extension
> > 
> > 2) This .vcxproj is essentially a C/C++ project, primarily because it has a compile AND link phase/target, unlike C# or VB, and I needed the link target for UWP apps
> > 
> > 3) The .vcxproj has additional targets to comply with the normal Ada build procedure (ie compile, BIND and link)
> > 
> > 4) The MSBUILD engine is used to co-ordinate the build, and invokes specific
> > targets that end up calling GPRBUILD with either the -c (compile), -b (bind)
> > or -l (link) command line options.
> > 
> > 5) if building UWP/WinrRT based apps, then the final GPRBUILD link is replaced
> > by a Microsoft linker command
> > 
> > 6) If the project "property Use Microsoft Linker" is set to YES (as is the case for
> > UWP/WinRT based projects) then their is an intervening step between the BIND and
> > Microsoft LINK phase which converts the GCC dwarf based debug information into
> > PDB format, so that you can debug the final app using Visual Studio.
> > 
> > 7) Note: An equivalent GPR file (to that of the above .vcxproj) is maintained
> > and re-generated when ever changes to the .vcxproj file are made.
> > 
> > Ok, with that knowledge in hand, lets try and isolate the build failure with the
> > following, using a VS x64 native command prompt, since this gives us a bit more
> > flexibility in running individual phase/targets in the build process.
> > 
> > (note I made some minor changes on GitHub, so you may want to do a git pull for
> > the winrt-runtime project, But I am not entirely convinced that these changes
> > ae the root cause) 
> > 
> > a) cd into the directory where your <project>.gpr file exists
> > 
> > b) gprbuild -f -c -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr
> > 
> >    this will only do the compilation phase, and should succeed, NOTE I am using
> >    the default MSYS2 install directories above in the -aP argument, which just
> >    tells GPRBUILD additional Project directories
> > 
> >    You should see the usual GPRBUILD compile phase output at this stage
> > 
> > c) gprbuild -f -b -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr
> > 
> >    This will then do the bind phase, and should succeed. If this fails, then
> >    please re-run, but ADD a -vh flag to the gprbuild cmd (ie gpbuild -vh -f …)
> >    this will give us some additional diagnostics that we can work with
> > 
> > d) If you got this far great, that means gcc/gnat is fine and we need to dig a
> > bit further. But now since gcc/gnat is out of the picture we need to use the
> > MSBUILD to diagnose the rest of the build cycle.
> > 
> > e) msbuild -target:clean
> 
> Sorry, I submitted this reply before I was ready to post, Anyway Continuing on
> 
>    the clean target should work fine (this step is NOT really required, but I
>    just want to make sure the expected targets are working as expected.)
> 
> f) msbuild -target:build
> 
>    this will do a build, and should be the same as the compile/bind phase in
>    point a) and b) above and the try and do the steps 5) and 6) mentioned above
> 
> g) Please check all /LIBPATH command line options in the LINK target, and report
> any unusual errors in using MSBUILD (except that you may see a error regarding
> not being able to find MSVCRT.LIB (I believe this is a false positive as I can
> build fine using VS)
> 
> 
> Thanks
> 
> Alex

Apologies, Before point e) above, please cd into the directory where the 
<project>.sln (ie Visual Studio solution exists) It should be 1/2 levels up
in the directory structure 

Alex

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

Very quick update, I will continue this weekend ...

"But now since gcc/gnat is out of the picture" does appear to be the case so far. Simply adding the -aP argument for both the compile and bind GPRBUILD commands did the trick (I'd already verified that WinRt.gpr was, in fact, in that location, so I figured it would work.)

Onward to MSBUILD. Will keep you updated.

Greg

P.S. I have NOT pulled the latest changes to winrt-runtime YET.

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

Aaaahhhhh ... the converter you mentioned in 6) above. Here are the steps of the MSBUILD task along with the top few lines of the stack trace when it rips.

AdaProject:
Skipping target "AdaProject" because all output files are up-to-date with respect to the input files.
AdaCompile:
  AdaCompileOutput = x64\Debug\RaceDirector.exe
  Compile
     [Ada]          racedirector.adb
     [Ada]          appoverrides.adb
     [Ada]          winmainstartup.adb
     [Ada]          guitask.adb
     [Ada]          locatortask.adb
     [Ada]          racedirectorxaml.adb
AdaBind:
  AdaCompileOutput = x64\Debug\RaceDirector.exe
  Bind
     [gprbind]      racedirector.bexch
     [Ada]          racedirector.ali
AdaConvert:
  AdaCompileOutput = x64\Debug\RaceDirector.exe

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at CV2PDB.{ctor}(CV2PDB* , SByte* ObjectFileName, PEImage* image)
   at InnerConvert(Char* argv)
   at AdaDwarf.Converters.ConvertDwarf(String FileName)
   at Ada.ConvertTask.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
 

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Saturday, May 4, 2019 at 12:53:09 PM UTC+10, Greg wrote:
> Aaaahhhhh ... the converter you mentioned in 6) above. Here are the steps of the MSBUILD task along with the top few lines of the stack trace when it rips.
> 
> AdaProject:
> Skipping target "AdaProject" because all output files are up-to-date with respect to the input files.
> AdaCompile:
>   AdaCompileOutput = x64\Debug\RaceDirector.exe
>   Compile
>      [Ada]          racedirector.adb
>      [Ada]          appoverrides.adb
>      [Ada]          winmainstartup.adb
>      [Ada]          guitask.adb
>      [Ada]          locatortask.adb
>      [Ada]          racedirectorxaml.adb
> AdaBind:
>   AdaCompileOutput = x64\Debug\RaceDirector.exe
>   Bind
>      [gprbind]      racedirector.bexch
>      [Ada]          racedirector.ali
> AdaConvert:
>   AdaCompileOutput = x64\Debug\RaceDirector.exe
> 
> Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
>    at CV2PDB.{ctor}(CV2PDB* , SByte* ObjectFileName, PEImage* image)
>    at InnerConvert(Char* argv)
>    at AdaDwarf.Converters.ConvertDwarf(String FileName)
>    at Ada.ConvertTask.Execute()
>    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
>    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
>    at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)

Hi Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Saturday, May 4, 2019 at 3:23:35 PM UTC+10, alby....@gmail.com wrote:
> On Saturday, May 4, 2019 at 12:53:09 PM UTC+10, Greg wrote:
> > Aaaahhhhh ... the converter you mentioned in 6) above. Here are the steps of the MSBUILD task along with the top few lines of the stack trace when it rips.
> > 
> > AdaProject:
> > Skipping target "AdaProject" because all output files are up-to-date with respect to the input files.
> > AdaCompile:
> >   AdaCompileOutput = x64\Debug\RaceDirector.exe
> >   Compile
> >      [Ada]          racedirector.adb
> >      [Ada]          appoverrides.adb
> >      [Ada]          winmainstartup.adb
> >      [Ada]          guitask.adb
> >      [Ada]          locatortask.adb
> >      [Ada]          racedirectorxaml.adb
> > AdaBind:
> >   AdaCompileOutput = x64\Debug\RaceDirector.exe
> >   Bind
> >      [gprbind]      racedirector.bexch
> >      [Ada]          racedirector.ali
> > AdaConvert:
> >   AdaCompileOutput = x64\Debug\RaceDirector.exe
> > 
> > Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
> >    at CV2PDB.{ctor}(CV2PDB* , SByte* ObjectFileName, PEImage* image)
> >    at InnerConvert(Char* argv)
> >    at AdaDwarf.Converters.ConvertDwarf(String FileName)
> >    at Ada.ConvertTask.Execute()
> >    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
> >    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
> >    at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
> 
> Hi Greg

Hi Greg

I found the issue (The conversion task was looking for mspdbcore.dll in the
Visual Studio 2015 distribution, and I strongly suspect that you don't have this
version of VS installed). I'll make it so that it will try and use the most
recent version available, either 2019 or 2017 (2015 is not supported by the
extension anyway)

I should be ably to push out a new VSIX later today (Australia Time) and be
ready for you Saturday morning (If I got my time calculations correct). This
version 1.2 will also include some other enhancements, which will be detailed
in the release notes

Thanks for the diagnostics, very helpful

Alex

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[Greg]

Absolutely, my pleasure. Yes, all three of my machines are various versions of 2017 and in the last few weeks, 2019. Looking forward to it!

Thanks,
Greg

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Saturday, May 4, 2019 at 11:31:36 PM UTC+10, Greg wrote:
> Absolutely, my pleasure. Yes, all three of my machines are various versions of 2017 and in the last few weeks, 2019. Looking forward to it!
> 
> Thanks,
> Greg

Hi Greg

Thanks, I'll try and get something out asap

Alex

Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper]

On Saturday, May 4, 2019 at 11:31:36 PM UTC+10, Greg wrote:
> Absolutely, my pleasure. Yes, all three of my machines are various versions of 2017 and in the last few weeks, 2019. Looking forward to it!
> 
> Thanks,
> Greg

Hi Greg

I have just released VisualAda version 1.2, which should fix the issue reported
earlier. Let me know if their are still issues with this

Alex