Здравствуйте, okon, Вы писали:

O>Правильно я услышал в книжке что райнтайм для .net core будет запекаться в само приложение при этом будет интегрироваться не весь рантайм, а только те его сборки которые подключены к приложению и не будет требоваться установка чего либо еще для запуска ?

UPD. Оф справка всяко надёжней. Читаем. И для веба.

Планируется несколько способов:

1. dotnet cli. Или автоматом собираем из исходников (в том числе автоматически, ч/з dnx-watch), или вытаскиваем готовую сборку из нюгета. Сам рантайм тож поставляется через нюгет, пакеты кэшируются.

2. AOT-компиляция с использованием текущего JIT. Официально её пока нет, но сам dotnet cli именно так и собран.

3. Полноценная трансляция с использованием .Net Native только в планах.


В любом из вариантов все зависимости, включая рантайм, тащатся следом за приложением, разница только в способе упаковки. Разделяемых между приложениями ресурсов и аналога GAC нет.

Здравствуйте, Serginio1, Вы писали:

Была такая ошибка, из-за нугета.
Помогло создание нового файла проекта.

Посмотрите лог билда
tracedesigntime

Правильно я услышал в книжке что райнтайм для .net core будет запекаться в само приложение при этом будет интегрироваться не весь рантайм, а только те его сборки которые подключены к приложению и не будет требоваться установка чего либо еще для запуска ?

Здравствуйте, Serginio1, Вы писали:

S>Может можно автоматически при компиляции приложения?
Из коробки, см "Deploying a self-contained app with third-party dependencies" вот тут и вот эту статью.

Свой хост в принципе можно оформить как команду dotnet cli, но это в issues .net cli надо спрашивать. Кое-как описано тут.

S> И еще вопрос. Как там сейчас расширения для Edge? И как для расширений .Net Core
JavaScript, пока никак — смысла нет.

Если вопрос про использование плагинов в самом .net сore (читай, в веб-приложениях), то см
http://shazwazza.com/post/custom-assembly-loading-with-aspnet-core/
и
https://csharp.christiannagel.com/2016/08/16/diwithconfiguration/

Здравствуйте, Serginio1, Вы писали:

S> Что то внятного на решение проблемы не нашел
И не будет. Тулинг деликатно обозван как preview, по факту цензурных слов для этого у меня нет.

Как минимум надо поставить VS 2015 Tooling Preview 2, там что-то похожее починили. И дальше поискать готовые примеры как вот тут советуют. Документация и тем более записи в блогах не успевает за "не, давайте вот так сделаем" от xproj team.

UPD А, да. И не пытайтесь скачать тулинг по ссылкам в оф.блоге. Не поставится. Чой-то товарищи взяли от linux way только самые худшие особенности

Здравствуйте, Serginio1, Вы писали:


S>и еще куча .json
S>А там ссылки на AngleSharp System.Data.SqlClient.dll

А надо смотреть, что именно используется для сборки. Если dotnet publish, а не dotnet build, то странно. Разница — в документашке.
https://docs.microsoft.com/ru-ru/dotnet/articles/core/tools/dotnet-publish
https://docs.microsoft.com/ru-ru/dotnet/articles/core/tools/dotnet-build

Ну и в какой-то момент оно было сломано, так что всё может быть.
Я ж говорю: сейчас при работе с .net core надо переучивать мозг. Вместо "просто работает" тулинг пока просто не работает, причём кучей разных способов.

Лично я пока забил на .net core, т.к. даже фундаментальные вещи меняются регулярно и изучать то, что есть сейчас, смысла ноль. А играть в "собрал hello world — значит умею в .net core" чего-то не тянет

Здравствуйте, Serginio1, Вы писали:

S>В publish она все используемые библиотеки взяла. В том числе и те которые идут с CoreClr.

Эмм, а у тебя модель — не portable app, а self-containing? Тогда так и должно быть.
Вот тут расписано.

Здравствуйте, Serginio1, Вы писали:

S> А в новом Edge всё на JS?
Расширения — да.

Здравствуйте, okon, Вы писали:

O>Правильно я услышал в книжке что райнтайм для .net core будет запекаться в само приложение при этом будет интегрироваться не весь рантайм, а только те его сборки которые подключены к приложению и не будет требоваться установка чего либо еще для запуска ?

Мне тоже интересно.

В моно такая фича давно реализована — в один бинарник можно положить и gc и jit и только те managed-сборки которые приложению нужны + machine.config. Только толку от этого мало. Полезно только для всяких Raspberry PI при нехватке места на Micro SD карте.

Проблема не в моно в самом линуксе — в .net core теже проблемы будут. Но сначала в MS должны научиться core хотя бы на любой линукс ставить.

Тебе для чего?

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, VladCore, Вы писали:

VC>>Забыли дописать на том другом сервере будет работать только если на нём теже зависимости тех эе версий что и там где этот бинарник собирал.
S>Не проблема как бы. Зависимости вместе с бинарником распространяются. Или вообще включаются прямо в него.

Я тебя расстрою. 100% проблема с libc.so и pthread.so — они без конкретного ядра не работают. первая ешё и по разному называется в разных дистрибутивах.

Проще рантайм в ядро засунуть — 100%. И выдавать разработчикам дистрибутивов наклейку "CLR Compliant Kernel" и "CLR Compliant Repo"
С вас 10 пенсов за идею



VC>>Для энтерпрайза сойдёт. Для публичной раздачи в таком бинарном виде — гемморой. Плюс проблемы с производительностью по сравнению с AOT-компиляцией.
S>Ну так для совсем публичной раздачи есть маркет и .net native.

Ну так под конкретную версию ядра отдельный натив. О том и речь. А линукс извините не гугл и не аппл делает — этих линуксов как грязи.


И про AOT я не зря написал — с ahead-of-time компиляцией менеджед сборок код заметно быстреееее. Энтрерпрайзу, а кроме него .NET на линуксе никому не нужен, оооочень нужна макс произодительность.

Кстати, В core-cli уже сделали AOT или ещё пилят? Судя по логам git что то там обновляют в AOT прям в июле

Здравствуйте, VladCore, Вы писали:

VC>Здравствуйте, okon, Вы писали:

O>>Правильно я услышал в книжке что райнтайм для .net core будет запекаться в само приложение при этом будет интегрироваться не весь рантайм, а только те его сборки которые подключены к приложению и не будет требоваться установка чего либо еще для запуска ?

VC>Мне тоже интересно.

VC>В моно такая фича давно реализована — в один бинарник можно положить и gc и jit и только те managed-сборки которые приложению нужны + machine.config. Только толку от этого мало. Полезно только для всяких Raspberry PI при нехватке места на Micro SD карте.

VC>Проблема не в моно в самом линуксе — в .net core теже проблемы будут. Но сначала в MS должны научиться core хотя бы на любой линукс ставить.

VC>Тебе для чего?

Да я пока просто изучаю книжку читаю.

Там написано .NET Core 1.0 the framework, including the runtime, is delivered with the application.
а также
Now you can deliver the runtime with the application and are not dependent on the version installed on the server

Здравствуйте, okon, Вы писали:


O>>>Правильно я услышал в книжке что райнтайм для .net core будет запекаться в само приложение при этом будет интегрироваться не весь рантайм, а только те его сборки которые подключены к приложению и не будет требоваться установка чего либо еще для запуска ?

O>Там написано .NET Core 1.0 the framework, including the runtime, is delivered with the application.
O>а также
O>Now you can deliver the runtime with the application and are not dependent on the version installed on the server

Забыли дописать на том другом сервере будет работать только если на нём теже зависимости тех эе версий что и там где этот бинарник собирал.

Для энтерпрайза сойдёт. Для публичной раздачи в таком бинарном виде — гемморой. Плюс проблемы с производительностью по сравнению с AOT-компиляцией.

Здравствуйте, VladCore, Вы писали:

VC>Забыли дописать на том другом сервере будет работать только если на нём теже зависимости тех эе версий что и там где этот бинарник собирал.
Не проблема как бы. Зависимости вместе с бинарником распространяются. Или вообще включаются прямо в него.

VC>Для энтерпрайза сойдёт. Для публичной раздачи в таком бинарном виде — гемморой. Плюс проблемы с производительностью по сравнению с AOT-компиляцией.
Ну так для совсем публичной раздачи есть маркет и .net native.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, VladCore, Вы писали:

VC>>Забыли дописать на том другом сервере будет работать только если на нём теже зависимости тех эе версий что и там где этот бинарник собирал.
S>Не проблема как бы. Зависимости вместе с бинарником распространяются. Или вообще включаются прямо в него.

VC>>Для энтерпрайза сойдёт. Для публичной раздачи в таком бинарном виде — гемморой. Плюс проблемы с производительностью по сравнению с AOT-компиляцией.
S>Ну так для совсем публичной раздачи есть маркет и .net native.

Мне сейчас к моей приблуде при запуске из из натива используя CoreClr.Dll при запуске .Net dll если в ней есть зависимости, то она из нугетов ничего не тянет. Приходится вручную все зависимые сборки копировать.
Может можно автоматически при компиляции приложения?

И еще вопрос. Как там сейчас расширения для Edge? И как для расширений .Net Core

Здравствуйте, Sinix, Вы писали:

Огромное спасибо! Буду разбираться.
S>> И еще вопрос. Как там сейчас расширения для Edge? И как для расширений .Net Core
S>JavaScript, пока никак — смысла нет.

А в новом Edge всё на JS? http://xdrv.ru/articles/software/331/full

Здравствуйте, VladCore, Вы писали:

VC>Проще рантайм в ядро засунуть — 100%. И выдавать разработчикам дистрибутивов наклейку "CLR Compliant Kernel" и "CLR Compliant Repo"
VC>С вас 10 пенсов за идею
А, вы в _этом_ смысле(с)?
Вот ХЗ как оно реализовано, но в рамках поддерживаемых платформ обещали xcopy deployment. Но это именно обещали, сам не копался. Список поддерживаемых тут, длиннющее обсуждение тут.

VC>Ну так под конкретную версию ядра отдельный натив. О том и речь. А линукс извините не гугл и не аппл делает — этих линуксов как грязи.
Ага, тут конь пока не валялся.

VC>И про AOT я не зря написал — с ahead-of-time компиляцией менеджед сборок код заметно быстреееее. Энтрерпрайзу, а кроме него .NET на линуксе никому не нужен, оооочень нужна макс произодительность.
Энтерпрайзу на сам .net core пока пофиг, чего уж там про производительность. ЦА первых версий — PHP-шники, стартаперы и прочая хипстота, их уже ничем не напугаешь.

А у разработчиков со стажем реакция обычно одна: "ну и как это использовать?"
Типовые примеры:
http://www.lhotka.net/weblog/WaitingForNETCoreTooling.aspx
и
https://ayende.com/blog/173825/dazed-and-confused-the-state-of-the-core

лучше всего текущее положение дел описывает вот эта комбинация постов:
1. Ожидания:

But if you "dotnet compile --native" you run it through the .NET Native chain and a larger EXE pops out. But that EXE is singular and native and just runs.

2. Реальность:

Note: At this point, only the helloworld and dotnetbot samples will work with native compilation.

(с)
и в итоге

According to the meeting we had, for RTM the users will have to manually call native, MCG, and other compilation pipeline commands. Post RTM we need to design a mechanism where commands can hook to each other to form a build execution graph.

(с)

Вот как-то так пока. Подход "взрослого" фреймворка — сначала делаем, потом раздаём обещания — мне что-то больше нравится. Бум надеяться, со временем .net core тоже переймёт эту культуру.


VC>Кстати, В core-cli уже сделали AOT или ещё пилят? Судя по логам git что то там обновляют в AOT прям в июле
Второе. Причём там то ли два, то ли три подхода к снаряду параллельно идёт:
* Собственно .net native, завязанный на mscpp-тулчайн
* llilc для трансляции в llvm
* текущий вариант aka "AOT для бедных" поверх существующего RyuJIT (crossgen tool, аналог ngen). Win x86 разумеется не поддерживается, т.к. RyuJIT там нет.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>>Может можно автоматически при компиляции приложения?
S>Из коробки, см "Deploying a self-contained app with third-party dependencies" вот тут и вот эту статью.

Блин если в студии делаю

"dependencies": {
   "Microsoft.NETCore.App": {
     "type": "platform",
     "version": "1.0.0"
   },

То все работает. Если

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0"
        },
        "TestCoreNetApp": "1.0.0",
        "System.Data.SqlClient": "4.1.0"
      },
      "imports": "dnxcore50"
    }
  },
  "runtimes": {
    "win10-x64": {},
    "win10-x86": {}
  }
}

То пишет

Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'win10-x86, win81-x86, win8-x86, win7-x86'. Possible causes:
1. The project has not been restored or restore failed — run `dotnet restore`
2. The project does not list one of 'win10-x86, win81-x86, win8-x86, win7-x86' in the 'runtimes' section.
3. You may be trying to publish a library, which is not supported. Use `dotnet pack` to distribute libraries.

Что то внятного на решение проблемы не нашел

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Что то внятного на решение проблемы не нашел
S>И не будет. Тулинг деликатно обозван как preview, по факту цензурных слов для этого у меня нет.

S>Как минимум надо поставить VS 2015 Tooling Preview 2, там что-то похожее починили. И дальше поискать готовые примеры как вот тут советуют. Документация и тем более записи в блогах не успевает за "не, давайте вот так сделаем" от xproj team.

S>UPD А, да. И не пытайтесь скачать тулинг по ссылкам в оф.блоге. Не поставится. Чой-то товарищи взяли от linux way только самые худшие особенности

Получилось. Но почему то вместо DLL только
hostfxr.dll
hostpolicy.dll
TestCoreNetApp.exe
TestCoreNetApp.dll

и еще куча .json
А там ссылки на AngleSharp System.Data.SqlClient.dll

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:


S>>и еще куча .json
S>>А там ссылки на AngleSharp System.Data.SqlClient.dll

S>А надо смотреть, что именно используется для сборки. Если dotnet publish, а не dotnet build, то странно. Разница — в документашке.
S>https://docs.microsoft.com/ru-ru/dotnet/articles/core/tools/dotnet-publish
S>https://docs.microsoft.com/ru-ru/dotnet/articles/core/tools/dotnet-build

S>Ну и в какой-то момент оно было сломано, так что всё может быть.
S>Я ж говорю: сейчас при работе с .net core надо переучивать мозг. Вместо "просто работает" тулинг пока просто не работает, причём кучей разных способов.

S>Лично я пока забил на .net core, т.к. даже фундаментальные вещи меняются регулярно и изучать то, что есть сейчас, смысла ноль. А играть в "собрал hello world — значит умею в .net core" чего-то не тянет

Ааа спасибо. Блин меня подводит незнания англицкого
вот

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {
    "AngleSharp": "0.9.7",
    "Microsoft.Extensions.DependencyModel": "1.0.0",
    "Microsoft.Extensions.PlatformAbstractions": "1.0.0"
  },
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0"
        },
        "System.Data.SqlClient": "4.1.0"
      },
      "imports": [ "dnxcore50", "portable-net45+win8+wp8+wpa81" ]

    }
  },
  "runtimes": {
    "win10-x64": {},
    "win10-x86": {}
  }
}

Сейчас добавлю publish и build и посмотрю разницу

Здравствуйте, Sinix, Вы писали:

S>Лично я пока забил на .net core, т.к. даже фундаментальные вещи меняются регулярно и изучать то, что есть сейчас, смысла ноль. А играть в "собрал hello world — значит умею в .net core" чего-то не тянет
В publish она все используемые библиотеки взяла. В том числе и те которые идут с CoreClr.
А вот как бы отделить от

c:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.0\

В TC сравнил каталоги. Этого достаточно. Огромное спасибо!