Веселая фича
имеем следующую конструкцию:
private static string DefaultCstFolder = TTemplatesDll.TemplateDir;
TTemplatesDll - синглетон
TemplateDir - проперть, контролирующая доступ к полю. Проперть критична и потому отслеживает ситуацию с своей инициализацией - выкидывае Ехцептион если что не так. Инициализация происходит в начале.
Вопрос - Каким образом она может оказаться НЕ инициализированной в средине выполнения программы, когда инициализация DefaultCstFolder уже давно позади?

CLR всего лишь гарантирует, что инициализация статического члена произойдёт до его первого использования. Ты уверен, что использование имело место быть? ;-)

100%...

Да, если интересно - только в Релеасе... в Дебуге все тип-топ...

По-русски это звучит так пошло...

перед и после первого использования DefaultCstFolder сделать записи в лог.

На основании чего сделан данный вывод? Измени геттер для TemplateDir:

string TemplateDir
{
  get
  {
     log.trace("TemplateDir: 1");
     try
     {
        //перед return:
        log.trace("TemplateDir: 2");
     }
     catch
     {
        log.trace("TemplateDir: 3"); 
        throw;
     }
  }
}

что будет в лог файле?

даже не хочу знать знать, о чём ты думал в 6-м классе, изучая одночлены и многочлены =))

На основании чего сделан данный вывод?
-----
На основании лога. Есть запись об инициализации, есть записи об доступе и в конце есть запись об Ехцептионе...
Не мучайся - в этом коде проблем нет. Проблема есть в другом месте - там создается (не мною) второй инстансе синглетона и он - не инициализирован...

ну так ССЗБ. приватный конструктор тебе в руки...

приватный конструктор тебе в руки...
------
Он и так приватный - указано же - синглетон...
ну так ССЗБ.
-----
Скорее - разработчиков Linq надо кормить звиздюлями...

Если конструктор приватный, как был создан второй объект данного класса? И чем тебе насолили создатели линка?

Как - это не ко мне, а аккурат к создателям Linq...

Ты не мог бы дать более расширенный ответ, а то я вообще не понимаю твои отрывки фраз :-(

Хммм... Ну хорошо...
Где-то в недрах Linq происходит вызов приватного конструктора TTemplatesDll или класс инстанцируется без вызова.
Причина такого поведения, скорее всего в том, что Linq сам по себе инстанцирует обьекты и делает это где-то в отдельном блоке памяти.
Как результат - там действительно создается другой инстансе singleton'a TTemplatesDll и он непаравильно инициализирован.
Наверное есть какой-то метод как сообщить Linq что ему нужен полный клон обьекта, но мне было лениво копать и обошел по-другому - убрал статику.

а можно привести конструкцию linq, посредством которой
Спасибо.

Могу дать завтра. Там удаление из списка.
Но сам код - не принципиален - любой код с использованием Линк будет делать тоже самое...

А тебе не кажется что в этом случае это просто не синглетон. Иначе говоря его кривая реализация.
Либо ты еще о чем умалчиваешь....

А тебе не кажется что в этом случае это просто не синглетон.
-----
Нее, не кажется... TTemplatesDll представляет единственную длл в системе... Мне просто вреден второй экземпляр...
Я так припоминаю, что уже была дискуссия по этому поводу... лет 5-6 назад...

Удаление из списка единственного члена? o_O

Едиственного члена Я прибью и без Линка...

А с каких пор ДЛЛ стала синглтоном? Я что то пропустил?

Представление Длл, однако, будет именно синглетоном... Ну не грузит же приложение две Длл... Хотя... Linq, похоже, грузит...
Да, вопросик попутnый образовался - загрузить Длл разными способами Я вроде умею... интересует - Как загрузить единичный класс из Длл?!.

Смешались вместе кони, люди... :)))

И так - код
[пре]
public class TTemplatesDll
{
string templateDir;
private TTemplatesDll()
{
}
private static TTemplatesDll instance;
public static TTemplatesDll Instance
{
get
{
if (instance == null)
{
instance = new TTemplatesDll();
instance.filename = defaultDllName;
}
return instance;
}
}
public static string TemplateDir
{
set
{
Instance.templateDir = value;
new TModules(value);
logger.Debug("TemplatesDir seted as " + value);
}
get
{
if (Instance.templateDir == null || Instance.templateDir == string.Empty)
{
throw new Exception("Pointer to Template's directory not initialized");
}
return Instance.templateDir;
}
}
}
public class TModules : List<TAbc>
{
private static string DefaultCstFolder = TTemplatesDll.TemplateDir;
public TModules(string pTemplatesDir)
{
/// обрезано
}
public int Remove() // падает с Ехцептионом на вызове этого метода. Сам метод - не выполняется.
{
return base.RemoveAll(x => !x.Exists());
}
}
public class TAbc
{
public bool Exsist() { ... }
}
[/пре]

линком то тут как раз и не пахнет.

RemoveAll(x => !x.Exists());

это не линк. RemoveAll - метод коллекции, принимающий предикат. в качестве предиката передана лямбда. так что одно уже выяснили на 100%: линк тут не причём. уже хорошо.
теперь давай перейдём к:

кашпировских тут нет :) так что давай чуть подробней: какой исключение? Тип, сообщение, стэктрейс.

какой исключение?
---
В коде только одно исключение. Именно оно и выбрасывается...
принимающий предикат.
-----
Ну а предикат-то как вычисляется?

тебе вопросы задавать - ацкая пытка :) или ты просто издеваешься? :)

тоесть кидается

new Exception("Pointer to Template's directory not initialized");

из геттера. так? ты ответил на 2/3 моего первого вопроса. приведи стэк-трейс, будь добр =)

Еще раз : лямбда-выражение представляет краткий способ создания предикатов и не имеет ничего общего с линк. :)

приведи стэк-трейс, будь добр =)
------
Чтобы это сделать надо открутить код на три-четыре дня назад. Даже если он и сохранился где-то - это туда-сюда положительного для задачи не даст, а времени займет много... Лучше Я поборюсь с Нулл-поинтером из-за недостатка памяти...
тебе вопросы задавать - ацкая пытка :)
-----
Так скопы-пасть код - он упадет и вопросов не будет...

так приведи минимальный код, который я смогу скомпилировать.
давай я тебе помогу:

using System;
using System.Collections.Generic;
namespace ConsoleApplication18
{
    public class TTemplatesDll
    {
        string templateDir;
        private TTemplatesDll()
        {
        }
        private static TTemplatesDll instance;
        public static TTemplatesDll Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new TTemplatesDll();
                    instance.templateDir = "uhhaha!!!";
                }
                return instance;
            }
        }
        public static string TemplateDir
        {
            set
            {
                Instance.templateDir = value;
                new TModules(value);
                System.Diagnostics.Debug.WriteLine("TemplatesDir seted as " + value);
            }
            get
            {
                if (Instance.templateDir == null || Instance.templateDir == string.Empty)
                {
                    throw new Exception("Pointer to Template's directory not initialized");
                }
                return Instance.templateDir;
            }
        }
    }
    public class TModules : List<TAbc>
    {
        private static string DefaultCstFolder = TTemplatesDll.TemplateDir;
        public TModules(string pTemplatesDir)
        {
            /// обрезано
        }
        public int Remove() // падает с Ехцептионом на вызове этого метода. Сам метод - не
 выполняется.
        {
            return base.RemoveAll(x => !x.Exists());
        }
    }
    public class TAbc
    {
        public bool Exists()
        {
            return true;
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            System.Console.WriteLine(TTemplatesDll.TemplateDir);
        }
    }
}

вывод:

uhhaha!!!
Drücken Sie eine beliebige Taste . . .

В первый раз встречаю, такое определение
Как то привык ориентироваться на другое.
http://csharpindepth.com/articles/general/singleton.aspx
http://msdn.microsoft.com/en-us/library/ff650316.aspx

Для каких целей, можно уточнить?
А в общем прицип простой - грузим длл-ку и вытаскиваем нужный тип
Assembly SampleAssembly;
SampleAssembly = Assembly.LoadFrom("c:\\Sample.Assembly.dll");
SampleAssembly.GetType("SuperPuperType",true);
Однако веселые часы получишь после :)
Весьма желательно грузить все требуемые Длл-ки в домейн приложения (все выбирается автоматом). Иначе рискуешь получить две копии какой нибудь длл-ки и после долго думать отчего "type1" != "type1"
Ну и в домейне также неплохо подписаться на ошибки загрузки длл-ок и типов.

СамплеАссемблы = Ассемблы.ЛоадФром("ц:\\Сампле.Ассемблы.длл");
------
Это - легко...
Даже класс из нее инстанцировать никакой сложности не представляет... это, кстати, именно тот класс который мне нужен...
Теперь , плс, перекомпилируй те из 650 шаблонов, которые требуют перекомпиляции... информация - аккурат в загруженном классе...
Первый момент - файл не доступен для записи... Хорошо - грузим в массив и инстанцируем и массива... Победили... однако памяти отожрали много...
Можно уменьшить расходы, сохраняя нужный мне класс в отдельной Длл... тоже работает... но получается много Дллок.
Хочется, однако, иметь одну (большую) Длл и не загружать ее несколько раз...
Потому спрашиваю - Как загрузить отдельный класс из Длл, не загружая саму Длл.
Что-то вида - прочитать заголовок, прочитатй кусок байтового аррея представляющий нужный мне класс и инстанцировать только этот класс из аррея...
и после долго думать отчего "тыпе1" != "тыпе1"
------
Похоже, что что-то похожее было...

Хммм... В немецком Я понимаю меньше чем свинья в апельсинах...
Говоришь - не падает... Ну пусть так... А у меня - упало... где не ожидал...
Отчего и почему - не знаю... и не интересно...
Сделал чтобы работало - и хорошо - там других проблем навалом...

да причём там немецкий... это вывод программы на консоль..
ладно, работает и ладно.

Пока еще смутно пониманию что тебе нужно. Чем тебя смущает Лоад?
Можно еще поиграться
с Assembly.ReflectionOnlyLoad и AppDomain
Или загрузить кучу твоих мелких дллок в ресурсы, а после грузить оттуда через стреам.

Пока еще смутно пониманию что тебе нужно.
------
Мне нужно получить из Длл информацию об тех шаблонах, которые она уже содержит.
После получения этой информации мне нужно добавить/удалить/заменить соответственно новые/удаленные/изненные шаблоны и обновленную информацию обратно в Длл..
Полную перекомпиляцию делать нежелательно - занимает слишком долго, а меняются обычно 1-2-3 шаблона за раз...
Ну а потом - загружать и гнать все на выполнение... Выполнялку Я сегодня дочинил... Осталось немного потоптаться на базовом коде шаблона и почистить все изделие... Баги там, конечно, еще есть, но оно уже супортабельное - понятно где ковырять при падении...

это вывод программы на консоль..
-----
Ааа... не обратил внимания на код...
За попутку разобраться - отдельное спасибо...
Сегодня была другая хохмочка...
Система - запускается... и работает... генерация кода - происходит... 100... 200... 400... 600... шаблонов отработали...
А потом - хлюп... и нулл-поинтер... причем шаблоны - те же самые... и выполнялка - та же самая...
Минут 15 не мог понять откуда проблема - все исходники доступны, все компилируется... хоть инкрементно, хоть с нуля...
И все одно - падает...
Потом догадался - версия шаблонов была от предыдущей генерации - изменений в них не было и их не перекомпилировало,
а изменения у меня были аккурат в базовом коде шаблонов...

Ну вот, после пыток стало немного проясняться.

долго это сколько на современном компе?
То бишь шаблоны это некие классы, а не спец. язык?
Какой "уровень наследования"? Что мешает сделать по шаблону на Длл-ку - только количество?

долго это сколько на современном компе?
-----
Долго - это дольше, чем может вытерпеть мой шеф...
А вытерпеть он может перекомпиляцию именно тех шаблонов, которые были изменены...
По поводу долго... иногда - долго... есть шаблон, содержащий минимизированную версию какой-то JS-либы... кажется 220 килобайт... минут пять идет конвертация в cs-класс...
Так и хочется выкинуть эту каку хотя бы в отдельный поток... но компилятор - однопоточный...
То бишь шаблоны это некие классы, а не спец. язык?
-----
Отдельный язык, компилируемый (своим компиляторм) в стандартные C# классы. Затем классы уже компилятся в модули... и по результатам еще и Длл лепится...
Какой "уровень наследования"?
-----
2-3... может и больше - я до конца еще не разобрался...
Что мешает сделать по шаблону на Длл-ку - только количество?
-----
Там есть неприятная зависимость от последовательности компиляции... Сейчас шаблоны группируются по модулям и система управляет порядком компиляции и выполнения этих групп/модулей... Если поменять порядок - может и не компилироваться... Разбираться с этим на уровне отдельного шаблона - редактировать в ручную файл в 600+ строк... и делать это каждый раз при добавлении нового шаблона... по 8-10 раз в день... и синхорнизация между разработчиками...

Ну вот, а говорил вот бы класс вытянуть из длл-ки
А нефиг С# генерить вместо IL
Компиляторы бы ваши поумнее сделать, что бы не генерили столько мусора.

Ну вот, а говорил вот бы класс вытянуть из длл-ки
------
Так оно и остается востребованным...
что бы не генерили столько мусора.
------
Хммм... может еще и где именно мусор лежит подскажешь? Я вот вчера добавил в один из шаблонов реального мусора - возможность выполнять вызов не относящейся к бизнес-обьекту процедурки на sql-сервере... А может и не мусор - разработчику нужен набор данных с сервера, а представления набора - нету... Придется изобретать как в трех строках описать процедуру как набор...
А нефиг C# генерить вместо IL
------
Это не ко мне - это к шефу... Бо, закажить IL будем делать IL... нам, Котам, пофиг что делать...

Если не делать из него инстанс, то можно решить либо чистой рефлексией либо из моно стыбрить парсер нетовских длл-ок.

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

для обычной задачи многовато.
------
Если он получается за 5 минут без напяга со стороны исполнителя и имеет гарантированно рабочую функциональность => пофиг размер...

О 5 минутах и гарантированную фукнциональность - это просто для более интересного рассказа?
А отчего тогда шеф не доволен временем и что ты правишь каждый день?

что ты правишь каждый день?
-----
Сам движек...
Шеф всегда нацелен на сделать как можно быстрее...
Ну а у меня цель - сделать более качественно, обеспечить сопровождаемость...
Это всегда занимает дольше... правда не дольше, чем писать и править спагетти...
для более интересного рассказа?
------
Приложение, обычно, порождается работоспособным... Но шаблоны надо весьма и
весьма вдумчиво чистить - там слишком много встроенного кода... который часто полное
спагетти...

То есть компиляция кодогнератора занимает дофига времени?

Что то мне кажется что твоя цель более правильна......

По идее любая готовая программа рабопособна,... в определенной ситауции.
А вот найти ошибку в гиге сгенерированного кода, думаю не такая уж и простая задача.

То есть компиляция кодогнератора занимает дофига времени?
------
Там кучка поцессов.
1. Компиляция собственно генератора. По времени - пустяки, тем более, что выполняется однократно...
2. Компиляция шаблонов. Тоже относительно не долго, но происходит гораздо чаще.
3. Кеширование схемы приложения (базы данных). Медленный процесс, мне хватает 1-го раза, а интегратору нужно раз 30 в час...
4. Генерация. Наиболее частый процесс. Последнее (мое) достижение - снизил времая генерации с 12 минут до 51 секунды.
5. Компиляция сгенерированного приложения. Тут странно - занимает дольше генерации...
6. Тестирование. Под вопросом - аккурат то, над чем мне работать на следующем этапе.
более правильна..
------
Но и более дорога. А денег вроде начинает катастрофически нехватать.
не такая уж и простая задача.
------
От того, что найдется ошибка в коде - ни холодно, ни жарко. Это как констатировать, что в выданной сдаче не хватает пяточка. Одна известна прямо сейчас - где-то в вызове sql-процедуры не подставляется OrderBy... при этом - есть критерий по умолчанию - по первичному ключу, но он не подставляется.
Теперь, как результат наличия ошибки, надо устанавливать она взялась - в исходных данных схемы (это легко), в конфигах (это тоже не сложно), в шаблонах (обьемно, но не сильно сложно), либо где-то в комплексе генератора (тут уже надо попыхтеть)...