Скомпилируйте агностика версии DLL в.NET
Я решил свою проблему. Вот решение:
$('#crop').click(function () {
var zoom = canvas.getZoom()
let top = zoneY // Top position of area
let left = zoneX// Left position of area
zoneWidth /= zoom
zoneHeight /= zoom
canvas.clipPath = shapeRect; // fabric.Rect()
canvas.renderAll()
})
Вместо обрезки изображения я обрезал сам холст. И используя положение области для обрезки
Вот заключительная демонстрация: https://jsfiddle.net/58nvte7h/43/
5 ответов
То, когда сопоставитель блока.NET не может найти блок, на который ссылаются, во времени выполнения (в этом случае, это не может найти конкретную обертку, DLL присваивает версию приложению, было связано против), его поведение по умолчанию состоит в том, чтобы привести к сбою и по существу разрушить приложение. Однако это поведение может быть переопределено путем сцепления AppDomain. Событие AssemblyResolve. Это событие запущено каждый раз, когда блок, на который ссылаются, не может быть найден, и это дает Вам возможность заменить другим блоком вместо недостающего (при условии, что они совместимы). Так, например, Вы могли заменить более старой версией обертки DLL, который Вы загружаете сами.
Лучшим способом я нашел, чтобы сделать, это должно добавить статического конструктора на основном классе приложения, которое сцепляет событие, например:
using System.Reflection;
static Program()
{
AppDomain.CurrentDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e)
{
AssemblyName requestedName = new AssemblyName(e.Name);
if (requestedName.Name == "Office11Wrapper")
{
// Put code here to load whatever version of the assembly you actually have
return Assembly.LoadFile("Office11Wrapper.DLL");
}
else
{
return null;
}
}
}
Путем помещения этого в статического конструктора основного класса приложения это, как гарантируют, будет работать, прежде чем любой код попытается получить доступ к чему-либо в обертке DLL, гарантируя, что рычаг существует заранее.
Можно также использовать файлы политики, чтобы сделать перенаправление версии, но это имеет тенденцию быть более сложным.
Просто мысль - Вы могли использовать TlbExp, чтобы создать два interop блока (с различными именами и блоками), и использовать интерфейс/фабрику для кодирования против двух через собственный интерфейс? После того как у Вас есть interop dll, Вам не нужна зависимость COM (кроме, конечно, для тестирования и т.д.).
TlbImp имеет/asmversion для версии, таким образом, он мог быть сделан как часть сценария сборки; но я уверен, что Вам даже нужно это: просто удостоверьтесь, что "определенная версия" является ложью в ссылке (проводник решения)?
Также - я знаю, что это не помогает, но C# 4.0 с dynamic и/или "Никакой PIA" не мог бы помочь здесь (в будущем; возможно).
Я не уверен, что полностью следую за всем, что Вы заявили, но позвольте мне попробовать:
Это кажется, что у Вас есть одно решение с 2(?) проектами. Каждый - реальное приложение, и другой обертка для Office API. Ваше приложение затем имеет ссылку проекта к Вашему Office обертка API. Я никогда не программировал для офиса прежде, но он кажется, что API программирования являются общим компонентом, из которого у Вас может только быть одна версия на машине (т.е. 2003 или 2007, не оба). И возможно это - то, где проблема, но потому что у Вас есть ссылка проекта, обертка будет скомпилирована сначала, скопирована в каталог bin Вашего приложения, где Ваше приложение будет связано с той сборкой обертки. Это заставит декларацию приложения конкретно запрашивать что версия обертки во время выполнения.
Если бы Вы имели обертку в разном решении и добавили ссылку на скомпилированную библиотеку, а не проект, то Вы всегда связывали бы свое приложение с той версией обертки, и Вы могли избежать проблемы.
Другим возможным выбором является Перенаправление Привязки сборки. Это более совершенствуется и идет со своим собственным набором проблем, но можно читать об этом здесь.
Или подобный идее Marc, Вы могли извлечь интерфейс и вытянуть некоторые общие объекты в библиотеку Framework и кодировать Ваше приложение против интерфейса и общих объектов. Затем при отражении использования во время выполнения, чтобы загрузить блок и инстанцировать обертки Вы хотите.
Я думаю, что ключ должен удалить зависимость проекта, если Вы можете. Это кажется, что обертка довольно стабильна и не изменяется, иначе Вы не попросили бы связываться с предыдущей версией его.
Установка Office 2003 и 2007 бок о бок на той же машине определенно возможна - мы делаем это в нашей организации даже на производственных рабочих станциях конечного пользователя.
В той связанной статье Microsoft рекомендует не сделать этого для фактического использования. Но в Вашем случае это, кажется, только для единственной машины сборки, т.е. Вы не собираетесь на самом деле использовать любую версию Office на той машине. В этом контексте я попытался бы видеть, можно ли сделать бок о бок работа установки.
Мое предположение могло бы быть неправильным, и Вы пытаетесь сделать это для машины каждого разработчика. В этом случае необходимо проигнорировать этот ответ :-)
Nice sleuthwork! I just threw together an implementation based on the concept presented above, and it works wonderfully:
static Assembly domain_AssemblyResolve(object sender, ResolveEventArgs args)
{
string partialName = args.Name.Substring(0, args.Name.IndexOf(','));
return Assembly.Load(new AssemblyName(partialName));
}
Of course there is room for enhancement, but this does the trick for me!