System.Drawing.Bitmap в ошибке WPF [дубликат]

Что вы хотите сделать с текстом? Является ли файл достаточно маленьким, чтобы вписаться в память? Я попытался бы найти самый простой способ обработки файла для ваших нужд. Для этого используется библиотека FileUtils.

for(String line: FileUtils.readLines("my-text-file"))
    System.out.println(line);
7
задан Michael Ratanapintha 20 January 2012 в 03:12
поделиться

4 ответа

.NET Common Language Infrastructure имеет две различные концепции:

  • Пространства имен: префиксы для имен типов, такие как System.Drawing, которые используются для различения нескольких типов, которые в противном случае имели бы одно и то же имя .
  • Ассемблирования: Библиотеки кода, которые могут быть развернуты, установлены и версированы отдельно от других сборок. Типы в сборке могут быть в любом количестве пространств имен.

Пространства имен образуют иерархию, основанную на разделителях полной остановки (точки), поэтому вы должны думать, что типы в пространстве имен System.Runtime.InteropServices подчинены тем, которые находятся в System.Runtime Пространство имен. Однако, насколько мне известно, CLI не заботится о имени или иерархии ваших пространств имен, за исключением тех случаев, когда они делают ваши имена типов уникальными.

Кроме того, сборка может содержать типы из нескольких пространств имен, даже в разных иерархиях, , а одно пространство имен может содержать типы, определенные в нескольких сборках. Если вы посмотрите на документацию MSDN для типа в библиотеках .NET он расскажет вам, какая именно эта сборка находится. Однако , как отметил Паоло Фалабелла, MSDN не сообщит вам, какая сборка имеет пространство имен, поскольку единое пространство имен может содержать типы из нескольких сборок.

В вашем сценарии: mscorlib - это сборка, которая определяет некоторые типы в пространстве имен System и многие другие, такие как System.Runtime.InteropServices, как вы отметили. Однако типы, которые вы используете в пространстве имен System.Drawing, находятся в сборке System.Drawing.

Поскольку сборки являются единицей развертывания и повторного использования кода, проекты Visual Studio ссылаются на сборки, а не на пространства имен и поэтому вы должны добавить ссылку на сборку System.Drawing в проекте Visual Studio для своей программы.

Оператор VB.NET Imports (и его эквивалент C #, using директива ) позволяет ссылаться на типы в пространстве имен , не вызывая каждый раз имя пространства имен. То есть, с помощью Imports System.Drawing, вы можете записать Graphics в свой код вместо System.Drawing.Graphics . Но это все оператор Imports. В частности:

  • Imports System не создает автоматически ссылки на проекты для каждой сборки в мире, которая определяет типы в пространстве имен System.
  • Imports mscorlib не означает, что вы ссылаетесь на каждый тип сборки «mscorlib» по его короткому имени. Это означает, что вы можете ссылаться на типы в пространстве имен mcorlib по их коротким именам, что не только совсем другое, но и вряд ли будет то, что вы хотите.

Итог: если вы хотите получить доступ к GDI +, то вы используете типы в пространстве имен System.Drawing, но это имя не имеет ничего общего с именем сборки GDI +. Microsoft выбрала имя «System.Drawing» для сборки, которая содержит типы GDI +, но она могла бы выбрать «gdiplus-cli», «gdi-for-dotnet» или даже «Frobinator». Независимо от того, какое имя имеет эта сборка, вы должны добавить ссылку на эту сборку. И вы не делаете этого в своем исходном коде - вы добавляете ссылки на сборки в своей конфигурации проекта Visual Studio.

MSDN имеет устаревшее, но все еще хорошее описание сборок , пространства имен и различия между ними, которые могут оказаться полезными.

14
ответ дан Community 19 August 2018 в 17:54
поделиться
  • 1
    Поэтому, если я правильно понимаю, imports System будет задействовать все сборки, которые определяют полное пространство имен System. С другой стороны, imports mscorlib будет тянуть только часть, определенную ее сборкой. – mdinger 20 January 2012 в 02:41
  • 2
    НЕТ! Оператор Imports работает только с пространствами имен. Он знает ничего о сборках. Я собираюсь изменить свой ответ, чтобы объяснить это. – Michael Ratanapintha 20 January 2012 в 02:55
  • 3
    Это различие в импорте, которое имеет большой смысл. Прежде чем объяснять это, я бы сказал, что ссылки делают доступными ресурсы для импорта, предоставляя местоположение файла ресурсов; однако ресурсы могут быть фактически доступны только через Imports. Спасибо за ваши усилия. Раньше я находил их очень озадачивающими и неясными. Теперь ссылки и импорт имеют гораздо больший смысл. – mdinger 21 January 2012 в 02:15

Даже после добавления System.Drawing в качестве ссылки, он все равно не может быть включен в проект.

0
ответ дан Clem 19 August 2018 в 17:54
поделиться

System.Drawing находится в отдельной сборке, к которой вам нужно обратиться.

1
ответ дан Joey 19 August 2018 в 17:54
поделиться

Пространство имен System.Drawing «живет» в другой dll, которая первоначально не упоминается в проекте шаблона для библиотеки классов. Вам нужно будет добавить ссылку на System.Drawing (щелкните правой кнопкой мыши по проекту -> добавить ссылку, System.Drawing - в GAC).

В MSDN вы можете увидеть, в какой сборке каждый класс «живет». Например, в документации для класса битмапа вы можете увидеть:

Пространство имен: System.Drawing

Сборка: System.Drawing (в System.Drawing.dll)

Обратите внимание, что на уровне пространства имен вы не можете найти информацию «Сборка», потому что вы можете добавлять классы в одно и то же пространство имен из разных сборок.

6
ответ дан Paolo Falabella 19 August 2018 в 17:54
поделиться
Другие вопросы по тегам:

Похожие вопросы: