MVV

Расписывать все преобразования не буду, изложу идею.

1. Раскрыть тангенс tg(x) по определению, как sin(x)/cos(x)
   
2. Расписать sin(2x) и cos(2x) по формуле синуса и косинуса двойного угла
   
3. Сократить числитель и знаменатель на 2*sin(x)
   
4. Привести выражение в числителе к общему знаменателю, перенести этот знаменатель вниз в основному знаменателю и сократить члены в числителе; в числителе останется sin(x)^2, в знаменателе - произведение трех сомножителей: -(1-cos(x)) и ещё двух, имеющих пределом 1
   
5. Выделить из числителя сомножитель (1-cos(x)) (см. в комментариях к предыдущему ответу) и сократить на него числитель и знаментаель
   

После этого в знаменателе не останется выржений, стремящих к 0, и можно будет посчитать предел нормальнм образом. Получится -2

В дополнение: есть такая утилита от Sysinternals (это уже давно часть Microsoft), она показывает все места, откуда возможен автоматический запуск, и что в этих местах содержится.

Если надо один раз: правой кнопкой мыши на нужный проект -> Debug -> Start New Instance
Если надо изменить на постоянку: правой кнопкой мыши на нужный проект -> Configure Startup Project...
или Меню->Project->Startup Project...
Предполагается, что все эти проекты входят в одно Решение (Solution)

У вас проблема с профилем пользователя на машине, с которой вы пытаетесь выпустить сертификат.
Закрытый ключ сертификата дожен храниться в профиле пользователя, а у вас там пользователь работает с временным профилем.
Разбирайтесь с загрузкой профиля при входе в систему: ищите события в журнале событий в момент входа, описывающие ошибку.

1. Чтобы Exchange Server принимал почту для другого домена, этот домен в нем должен быть прописан в Обслуживаемых доменах с типом "Внутренняя ретрансляция". А для фактической отправки почты на другой домен нужно создать соединитель отправки для этого домена с назначением (smarthost) на сервер, фактически обслуживающий этот домен. Сервер на том конце может быть совершенно любым сервером SMTP.
2. Адреса для п/я в Exchange настраиваются политиками адресов: в политике должен быть прописан первичный домен для адреса SMTP (используется и для отправки и для приема) и может быть несколько вторичных доменов. На той стороне, где нужно поменять адреса, просто добавьте в политику нужный домен с нужным типом. Кстати, если политика поменяет первичнй адрес п/я, то его бывший первичный адрес останется в качестве вторичного, так что, если новым пользователям не нужно добавлять адреса из старого домена, то в политике можно просто заменить первичный домен на новый, не оставляя старый вторичным.
3. Чтобы письма с Exchange с адресом его обслуживаемого домена могли отправляться на другой сервер SMTP (в том числе - в Exchange в другом лесу), нужно сменить тип этого домена с полномочного на внутреннюю ретрансляциию и создать соединитель отправки аналогично п.1
4. Вам наверняка потребуется синхронизировать адресные книги обоих Exchange. Раньше для этого можно было использовать бесплатный упрощенный вариант Microsoft Identity Integration Server (названия у него были разные, но суть одна: синхронизация AD между разными лесами, так чтобы пользователи с п/я из одного леса отображались как контакты в другом). Остался ли он сейчас - не интересовался. Но, в принципе, это может делаться и скриптом.
5. Вариантов совместного использования Exchange много разных (например, можно сделать общие календари). Но тут я их рассматривать не буду - вы все равно, скорее всего, захотите все это поскорее мигрировать в один лес. Но если интересно - ищите книги/документацию по Exchange 2007: эта функция (называется "федерация") в современном виде появилась там, и лучшие описания относятся именно к этой версии. С тех пор мало что поменялось, потому что MS пошла в облака.
6. При миграции есть возможность заводить п/я в одном лесу для пользователей из другого, доверенного леса (называется это Linked Mailbox, как по-русски - точно не помню). Для этого, кстати,в Exchange есть скрипт (его использовали для подготовки миграции с ADMT или ему подобными).

Get-WinEvent -LogName Application -MaxEvents 10 | Format-List Machinename, TimeCreated, Message

Ответ на вопрос "как хранить" зависит от того, какие данные вы будете запрашивать. То есть - от представлений данных, с которыми работает ваша программа (программы). Именно на основе этих представлений синтезируется полная модель даннных, хранящаяся в БД.
В свое время, лет 25 назад, был (может, и сейчас есть) стандартизированный подход, называвшийся IDEF1 (это имя из стандарта) или Entity-RelationShip (это название процедуры), позволявший формальным образом синтезировать из этих, частных, представлений полную модель данных. И были программы, которые позволяли это делать. Я одной такой пользовался, ERwin называлась (AFAIK она жива и сейчас), но, в принципе, нужные процедуры можно выполнять и вручную. Описание процедуры на русском есть, как минимум одно, которое я знаю - в старой книге "Мартин Дж. Организация баз данных в вычислительных..."
Короче, синтез модели ваших данных - это ваша задача, связанная со специфическими вашими задачами.
Судя по информации из вашего вопроса, я могу только сказать, что:
1. этот вариант вам явно не походит: данные из представления "Товары в корзине" включают товары из всех категорий, так что отделные таблицы для каждой категории - это костыль: ходить можно, а бежать - уже нет.
2. В ItemOptions можно хранить данные для всех категорий - достаточно указать в каждой записи дополнительно к идентификатору товара идентификатор категории и идентификатор свойства. Потребуются ещё таблица категорий (идентификатор категории как первичный ключ плюс дополнительная информаци) и таблица свойств для каждой из категорий (идентифкатор свойства как первичный ключ, идентификатор категории - внешний, плюс дополнительная информация). Схема получается не очень уклюжая, но для работы в рамках реляционной модели более-менее годная (я когда-то такую и делал и с ней работал, но это было жутко давно). Насколько для вас такая схема пригодна - зависит от ваших моделей предствалений: например, будете ли вы в Корзине указывать дополнительную информацию из ItemOptions.
3. NoSQL - это название больше коммерческое, а не техничекое: оно включает много разных технологий хранения в БД, единственным общим признаком которых является, что они - не реляционные. Под эту задачу мне видится годным вариант навигационной БД (это где каждая запись содержит физические ссылки на связанные с ней записи): сетевая, например. В настоящее время такие БД иногда ещё проходят под псевдонимом "графовая". Но, опять же, смотрите на нужные вам представления, в данном случае - обращайте внимание на пути доступа к данным (эти самые ссылки): навигационные БД в этом плане не так гибки, как реляционные, и отсутствие нужных ссылок может заставить ходить по кривым путям и убить тем самым производительность.
Но это все теория, а что там сейчас на практике творится - я с уверенностью сказать не могу. Насколько я понимаю, там надо смотреь возможности конкретной СУБД - тем более, что производители часто называют их словом "гибридная", и надо понимать, что в этот гибрид попадает.