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

[alby.gamper@gmail.com]

On Saturday, May 11, 2019 at 7:15:33 AM UTC+10, Greg wrote:
> Quick thoughts:
> 
> 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 would be massively good, one less step (actually more than one) to get up and running with a real Ada/UWP app. Just so I'm clear ... you mean a separate NuGet package for each Win10 SDK version, i.e. 1803/17134? Not sure I've seen that methodology, but I'm sure it's used. And for example, my personal stuff is running (now) Insiders with 18362 while my work laptop is currently suffering with 16299.
> 
> 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.
> 
> At first I thought, nah, I'd dump it because for my personal use cases (right now, anyway), I don't really have a use for it. I was just trying to break - sorry, I mean test :) - the different templates. But in enterprise situations, where you often couldn't care less about Windows Store - sure, it'd be very valuable. I mean, I build "common" DLLs (.NET) all the time, each used by 3-4 different apps. Absolutely.
> 
> ... personally - and quite selfishly - I'd rather see Intellisense advance (which you've mentioned in your READMEs I know) , Object Explorer support of some kind, (probably the same thing, but then again I've never added that sort of extension support for a language before.) You know, the whole VS kind of stuff we've all come to expect and love (I've never been one to say, "hey, I'm a REAL developer - I don't NEED Intellisense" :))

Hi Greg

Sounds like Nuget and Intellisense are my next priorities (Intellisense always
was, just haven't found a good solution yet) A couple of point for each

Nuget:

1) It probably makes sense for the WinRT Nuget to be versioned to the MS SDK version.
WinRT is after all is COM based, and linking in 19H1 libs when and trying to use
features of 19H1 (inadvertently) when you are running 1803 will cause problems.

I have already created a 1809 branch on Git (current master is 19H1). So I can
go back and create branches for 1803, 1709 .. etc if needed. Note 19362 SDK has
been released ahead of the official Windows 10 19H1 release

2) Or I could/should do version checking within the WinRt bindings themselves
and if their is a mismatch then raise an Ada exception before calling the actual Api

Intellisense: 

Their a few ways of doing this, all with pros and cons, these being

1) Extend the current use of ANTLR, which at the moment is just being used for
syntax colouring and Outlining (BraceMatching and BraceCompletion are handled
outside of ANTLR since the functionality does not require a full lexer/parser)

   I am not convinced the above is doable ?

2) Use the Adacore ada_language_server in conjunction with the MS supplied
Nuget package "Microsoft.VisualStudio.LanguageServer.Client" (which supplies a
default implementation of a LSP client). This is fairly easy to implement, However
the experience (thru no fault of AdaCore) I believe is not ideal. This is because I believe (as a fallback)
VS adds what it thinks are valid completions based on a dictionary of words in
the current document, which pollutes intellisense.

(FYI) Note that AdaCore's implementation of Ada_Language_Server is reliant upon their
LibAdaLang/LangKit GitHub projects.

3) Develop/use a Ada-COM wrapper over the functionality provided by AdaCore's
LibAdaLang and integrate this with the VS native Intellisense interfaces. This may sound
a bit over the top, But it does allow mapping between the LibAdaLang supplied
AST to that expected by VS Intellisense native interfaces.

The only problem/issue with this approach is that VS extensions (Like VisualAda)
must target win32 (Since VS is actually a 32 bit app and It cant easily access a
64 bit app,COM dll). So building a LibAdaLang 32 bit library may be problematic.
I believe this is possible, but reliant on availability of recent GCC 32 bit
compilers.

The above points are just food for thought (so to speak)

Alex

NOTE:

Ive got a new release 1.2.1 ready which resolves the following issue you had

1)UWP DLL project - link error (libgnat-8). This is actually caused by trying to generate both
a GCC lib and a MS LIB and is caused by issue with the supplied MS ada.targets file
2) UWP XML application dependencies are now resolved, and will build the <App>XML
project before the <App> project, which is what is expected.
3) If you have not already encountered issues with install/uninstall functionality
then these are now resolved (Note it really only makes sense to install/uninstall
library based projects??