在Ada中使用.net命令 [英] Using .net commands in Ada

问题描述

我知道，这是一个noob问题，但.....我不知道:(



我使用的是dotnet-gnat，我我在使用平台的命令时遇到了麻烦。在Ada中使用Net ...我可以使用WriteLine，但ReadLine命令，我不能......

如何知道正确的方法使用一些命令？



我的代码：

I know, it''s a noob question but..... I don''t know :(

I am using dotnet-gnat, I''m having trouble using the commands of the platform. Net in Ada ... I can use the WriteLine, but the ReadLine command, I can not ....
How to know the correct way to use some command?

My code:

with Ada.Text_IO, MSSyst.Console;
use  Ada.Text_IO, MSSyst.Console;

procedure ada_net is
begin
    Put("Ola mundo");
    New_line;
    WriteLine("Ola mundo");
    --ReadLine;
end ada_net;

ReadLine代码：

ReadLine code:

function ReadLine  return access MSSyst.String.Typ'Class;
pragma Export (CIL, ReadLine, "ReadLine");

谢谢。

Thanks.

推荐答案

问题在于.NET绑定还没有建成。如果你看一些示例Ada .NET项目，你会发现一些doinclude.bat或prebuild.bat文件。它们应该构建所需的绑定。



它可能如下所示：

The problem is that the .NET bindings are not yet built. If you look at some of the sample Ada .NET projects, you will find some "doinclude.bat" or "prebuild.bat" files. They are supposed to build the required binding.

It might look like this:

cil2ada mscorlib.dll  -quiet
cil2ada System.dll -quiet
cil2ada System.Drawing.dll -quiet
cil2ada System.Windows.Forms.dll -quiet

这不仅会创建可怕的Ada包声明代码，每个.NET类型的包和文件，还有 MSSyst 顶级命名空间（而不是系统...... ），它实际上不起作用。原因很简单：GNAT for .NET，即使是最新的2012版本，也只针对.NET Framework和.NET Framework v.2.0;此外，在Windows上，它仅针对x86（32位）指令集架构。



问题是：所有现代计算机都使用64位指令集只有，最典型的是x86-64。 32位指令集架构可通过WOW64获得：

http://en.wikipedia.org / wiki / WOW64 [ ^ ]。



由于在大多数计算机上安装了更高版本的.NET Framework，因此问题更加复杂。当您运行AdaCore批处理文件时，它将报告不是有效的.NET程序集，但仅仅因为程序集的默认版本似乎是v.3.4,4.0或4.5，为2.0构建的GNAT应用程序无法识别它。



手动解决方法可以很简单。您需要通过其主要可执行模块名称的文件名，按名称和显示的版本，特别是文件路径中的所有GAC（http://en.wikipedia.org/wiki/Global_Assembly_Cache [ ^ ]）。进一步的问题是，.NET API不够自洽，无法遍历整个GAC;这个问题的解决方案存在，但是在.NET之外并且是特定于Windows的。



现在，对于第一个手动步骤，我只使用文件找到了所有必需的文件搜索。可以修改批处理文件以提供绝对路径。以下是修改后的样本：

Not only this creates horrific Ada package declaration codes, a package and file per .NET type, with MSSyst top-level namespaces (instead of System...), it actually does not work. The reason is very simple: GNAT for .NET, even the latest 2012 version, is targeted to .NET Framework and .NET Framework v.2.0 only; moreover, on Windows, it is only targeted to x86 (32-bit) instruction-set architecture.

The problem is: all modern computers use 64-bit instruction sets only, most typically x86-64. The 32-bit instruction-set architectures are available via WOW64:
http://en.wikipedia.org/wiki/WOW64[^].

The problem is further complicated by the fact that on most computers, later versions of .NET Framework are installed. When you run the AdaCore batch file, it will report "not a valid .NET assembly", but only because the "default" version of the assembly appears to be v.3.4, 4.0 or 4.5, GNAT application built for 2.0 cannot recognize it.

The "manual" work-around can be simple enough. You need to find out appropriate versions of the required assemblies by the file names of their main executable module names, by name and the version shown, in particular, in the file paths, in all of the GAC (http://en.wikipedia.org/wiki/Global_Assembly_Cache[^]). Further problem is that .NET API is not self-consistent enough to traverse the whole GAC; the solution of this problem exists, but outside .NET and is Windows-specific.

Now, for a first manual step, I found all required files using just the file search. The batch file can be modified to provide absolute paths. Here is the modified sample:

cil2ada c:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll  -quiet
cil2ada c:\Windows\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll -quiet
cil2ada c:\Windows\assembly\GAC_MSIL\System.Drawing\2.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll -quiet
cil2ada c:\Windows\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll -quiet

请在控制台中执行cil2ada以查看更多详细信息。



我留下了一些必须修复的细节。生成的包规范的子目录不是批量创建的，我做到了。可以使用cil2ada的cd include - o命令行参数代替。



目标是生成所有绑定的Ada包规范一次并重用它对于解决方案或计算机中的所有GNAT项目。可以将解决方案的生成添加到解决方案中;并且应该在解决方案文件中规定项目依赖项，以确保生成的文件在构建之前可用。



下一步需要修复* .GRP文件。看看这一行：

Please execute "cil2ada" in console to see more detail.

I left some detail which had to be fixed. The subdirectory for generated package specification was not created in batch, I did it. Instead of "cd include" "-o" command-line parameter of cil2ada can be used.

The goal is to generate all binding Ada package specifications once and reuse it for all GNAT project in the solution or the computer. The generation of the package specifications can be added to the solution; and the project dependencies should be prescribed in solution file, to ensure that the generated files are available before build.

Next step needs fixing of the *.GRP files. Take a look at this line:

for Source_Dirs use (".");

（这是一个遗憾，但AdaCore与Visual Studio的集成非常糟糕。项目中包含的项目不是由项目结构定义，而是由此行定义。如果您创建项目子目录，正如项目结构所规定的那样，它不会工作。同时，一些未添加到项目结构中的文件将通过这个GPR指令连接起来。真的很脏的工作... :-(）

假设我在解决方案项目目录上方的目录结构级别生成了include子目录，以使所有这些include可以重用。然后你需要将它添加到这个指令中：



用于Source_Dirs使用（。，.. \ .. \ include）;



这使.NET项目编译。



到目前为止，它看起来很丑陋。真实的解决方案将成为项目像任何其他.NET项目一样工作。我知道如何在项目结构层面上做到这一点，但是Visual Studio中的集成需要以文明的方式重写相应的Visual Studio插件。看一下.NET绑定的一般质量和迄今为止过时的Framework目标，我仍然不相信它是否值得付出努力。相反，值得做出概念验证，以确保所有Ada 2012的力量都能得到有效利用......



现在，如何处理最丑陋的问题，如何在GAC中使用适当版本的文件自动生成绑定？一种方法可以是使用Reflection来发现GAC项目的简单C＃预构建项目。如果您将此项目简单地定位到x86 CPU指令集和.NET Framework v.2.0（无论需要什么样的风格），Reflection将帮助您通过某些代表性类型找到GAC程序集。技术很简单，项目的目标确保正确的版本;而且工作繁琐但只能做一次;并且可以根据需要添加项目。这个想法清楚了吗？无论如何，这种解决方案的细节可能还需要另一个答案...

-SA

(This is a shame, but the AdaCore integration with Visual Studio is pretty bad. The items included in the project are defined not by the project structure, but just by this line. If you create a project sub-directory, as the project structure dictates, it won''t work. At the same time, some files not added in the project structure, will be hooked up through this GPR "instruction". Really dirty work… :-()

Suppose I generated "include" sub-directory at the directory structure level above the directories of the projects of the solution, to make this "include" reusable by all of them. Then you need to add it to this instruction:

for Source_Dirs use (".", "..\..\include");

That makes the .NET projects compile.

So far, it looks quite ugly. The real solution would make the project work as any other .NET project. I know how to do it at the level of project structure, but integration in the Visual Studio need rewriting of the appropriate Visual Studio add-on in a "civilized" way. Looking at the general quality of .NET binding and by far outdated Framework targets, I''m still not convinced if it worth the effort. Rather, it worth making a proof of concept to make sure that all that Ada 2012 power could be effectively leveraged…

Now, what to do with the ugliest problem, how to automate generation of the binding with appropriate versions of the file in GAC? One approach could be a simple C# "pre-build" project using Reflection to discover GAC items. If you simple target this project to x86 CPU instruction-set and v.2.0 of .NET Framework (whatever flavor is required), Reflection will help you to locate the GAC assemblies by some representative types. The technique is simple, the project''s target ensure correct versions; and the work is tedious but can be done just once; and the items can be added as they are required. Is this idea clear? Anyway, the detail of such solution would probably need yet another answer…

—SA

在.NET GAC的自动绑定Ada软件包上发布承诺的代码。



在紧要关头，您可以创建一些C＃应用程序并添加引用所有程序集想要有;例如，整个GAC。此代码将自动检测所有引用的程序集，找到它们并调用cil2ada：

Posting the promised code on the automatic of the binding Ada packages for .NET GAC.

In a pinch, you can create some C# application and add referenced to all assemblies you want to have; for example, the whole GAC. This code will automatically detect all referenced assemblies, locate them and call cil2ada:

Assembly entryAssembly = Assembly.GetEntryAssembly();
string entryAssemblyPath = System.IO.Path.GetDirectoryName(entryAssembly.Location);
Assembly[] referencedAssemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly referencedAssembly in referencedAssemblies) {
    string location = referencedAssembly.Location;
    string path = System.IO.Path.GetDirectoryName(location);
    if (path == entryAssemblyPath) continue;
    Console.WriteLine(location);
    System.Diagnostics.ProcessStartInfo info =
        new System.Diagnostics.ProcessStartInfo("cil2ada.exe", string.Format(@"{0} -o .\sub", location));
    info.CreateNoWindow = true;
    info.UseShellExecute = false;
    System.Diagnostics.Process process = System.Diagnostics.Process.Start(info);
    process.WaitForExit();
} // loop

此代码中的关键是 AppDomain.CurrentDomain.GetAssemblies（）。如果你试图从条目程序集中获取所有引用的程序集，它只会列出实际使用的程序集（让我们说，其他程序将被优化），这不是你的需要。



同样，这里的主要问题是没有像样的Visual Studio绑定。在正常绑定中，MSBuild 任务查找引用的程序集，因为它们出现在项目文件中，找到它们，并在临时目录中生成绑定（通常在目标文件）。项目中文件集的存在也保证使用文件标记，因此增量构建永远不会重新构建以前准备的项目。 GNAT绑定完全忽略了大部分项目内容，完全依赖于GPR文件内容，这可能与项目相矛盾，但最终会影响构建。



我很乐意解决这个问题如果我对GNAT有足够的信心，可以通过构建真正的Visual Studio绑定来解决问题。现在，我真的不相信这个实现。虽然学习一些语言已经足够好了。

-SA

The key thing in this code is AppDomain.CurrentDomain.GetAssemblies(). If you tried to get all referenced assemblies from the entry assemblies, it would only list assemblies which are actually used (let''s say, others will be "optimized out"), which is not what you need.

Again, the major problem here is that there is no decent Visual Studio binding. In decent binding, the MSBuild task looks up the set of referenced assemblies as they appear in project file, locates them, and generates binding in the temporary directory (typically, under "obj"). The presence of the file sets in the project also guarantees using file stamps, so incremental build never re-build previously prepared items. And GNAT binding simply ignored most of the project content, relying solely on GPR file content, which can contradict the project but ultimately governs the build.

I could gladly solved this problem by building "real" Visual Studio binding if I had enough faith in GNAT. Right now, I cannot really trust this implementation. It''s good enough to learn some language though.

—SA

这篇关于在Ada中使用.net命令的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！