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

[Optikos <optikos@verizon.net>]

On Friday, May 10, 2019 at 7:08:30 AM UTC-5, alby....@gmail.com wrote:
> On Thursday, May 9, 2019 at 7:20:14 AM UTC+10, Greg wrote:
> > Alex, sorry, been hammered with deadlines and too tired at night to even look at a screen.
> > 
> > 1) and 2) would go a long way to helping others starting down this path, and that's the point, at least from my perspective. Everyone talks about promoting the language, and to me, this is one of the more outstanding ways I've seen.
> > 
> > 3) I can't believe you can't set dependencies as you say, but who knows, you might be right. If not, a mention in the README should certainly be sufficient.
> > 
> > 4) Figured something like that.
> > 
> > 5) I did monkey around with changing the target runtimes myself to more recent ones, but didn't seem to make much difference, but defaulting to more recent ones is definitely the way to go.
> > 
> > I guess just emphasizing that you HAVE to build THIS and THIS first (the WinRT stuff) before using Visual Ada, you know, step A, B, and C - as you said, would help a lot. 
> > 
> > I suppose I could start doing PRs for documentation suggestions or other issues of course, on the WinRT stuff. When/if VisualAda goes to GitHub, same thing.
> > 
> > I'm just having fun doing this, and hey, anything I can do to help. I have absolutely no need for GtkAda, and doing a Windows app in Ada is still to me  mind-blowing.
> > 
> > I did try to build a UWP DLL the other day and ran into an error, can't remember what it was exactly, but when I get a chance, I'll pass along the details.
> > 
> > I strongly suspect deploying a VisualAda UWP app to Xbox WILL work, just haven't had the chance to set it up yet. But will soon.
> > 
> > Again, thanks for all of this incredible work,
> > Greg
> 
> Hi Greg
> 
> I apologise, I actually missed this post (and replied to you later post without
> seeing this one). So in response to your points, which are very much appreciated
> 
> 1) and 2) I have already posted some changes to the GitHub readme's for both
> winrt_runtime and winrt project to reflect the dependencies and additional info.
> PR's are very welcome for the documentation, But bear in mind that the winrt
> source code is generated of the back of the winmd metadata, so changes to the
> bindings need to be generic!. I am happy to accept PR's for winrt_runtime.
> 
> BTW, Thanks for your comment's regarding my work, I in part embarked on this
> journey. because I saw a need to promote Ada outside of its traditional use
> case in the safety critical/embedded/Realtime markets and I always considered
> Ada as a general purpose language applicable to any environment. To this end I
> saw that providing bindings to Win32, WinRT and providing "Visual Studio"
> integration would encourage young graduates / IT professionals to at least be
> given the tools to develop great Ada applications in a familiar development IDE
> and lets face it, MS does have an impact (be it free or other wise) on the
> choice of what IDE is used within an IT shop.
> 
> 3) I have done some more research (ie googling) and may have found a workaround
> to being able to set project dependencies for VS solutions with multiple
> projects, have a look in your spare time :-) TL:DR
> 
> https://blog.tonysneed.com/2011/09/14/build-a-multi-project-visual-studio-template/
> 
> 4) and 5) I have as yet not had a chance to look at this in detail yet, will
> do this over the weekend, while looking at the packaging/install issue with
> VisualAda.
> 
> On a side note: what's your thoughts on the following idea's
> 
> a) Use Nuget to install/reference the WinRT dependencies. But this does mean
> that each UWP app has its own copy of the WinRT dependencies. Not ideal in my
> view (unless of course you are diligent and update your refences regularly) and
> definably / probably NOT workable in a very disciplined IT environment.

This is the practice in place for all nugets.  It is not as unwise as it first appears.  This practice allows a decoupling of each project so that different projects can update to different nuget dependencies as that project sees fit internally.  If not on a per-project basis for what that project/executable/library needs for its own internal needs, then on what basis?
1) one size fits all projects resident on some developer's individual Windows 10 computer?
2) one size fits all across all developers in a software-development department?
3) one size fits all across an IT department (or per-.NET-programming-language coding-standards culture) serving multiple software-development departments?
4) one size fits all across a campus?
5) one size fits all across all campuses of an entire corporation?
6) one size fits all across the entire universe of all corporations?

Or in fewer words, there is a method to Microsoft's madness.  :-) 

> b) I am not sure that a UWP app can be distributed with a "native DLL" via
> Windows Store (as opposed to statically linking to a LIB). If it cant, do you
> see any value in keeping the "UWP DLL" template ? Note that apps that are side
> loaded (ie within a corporate env and NOT distributed via the Windows Store) are
> not under the same restriction

Although I have not personally distributed a UWP app that contains a Win32 or WoW DLL (that obeys the subset-of-the-Win32-API restrictions) in the Microsoft Store, it appears to be permitted, if enough requisites are satisfied:
https://social.msdn.microsoft.com/forums/windowsapps/en-us/c5636e14-422f-4ab0-b608-2609ad8198e4/metro-style-app-how-to-load-win32-dll

Does the DLL in question in VisualAda confine itself to the UWP-compliant subset of the Win32 API?