Angelina_Joulie

Обычно это делают так:
1. Общие сборки выделяют в отдельный проект
2. Пишут build script (в самом простом случаи .sln подходит)
3. Устанавливается NuGet
4. Собирается .nuspec-файл и на вкладывают в него все сборки (см. п1)

Для автоматизации процесса настраивается continue intergration (CI) билд-сервер, который бы при каждом изменении собирал бы общие сборки и отправлял в NuGet Repository, откуда все заинтересованные проекты бы подтягивали по мере необходимости.

Вот первая ссылка из Гугл
www.hanselman.com/blog/NuGetForTheEnterpriseNuGetInAContinuousIntegrationAutomatedBuildSystem.aspx

Будут вопросы — обращайтесь в почту.

сорри, айпад тупанул.
Хотела сказать: НЕ РАБОТАЕТ с сложными хранимыми процедурами

а как вы вообще себе использование представляете?

что бы оно потом возвращало System.Object а вы после этого проверяли, а какие же параметры передавались и какой объект на основании этого получился?

Вам не кажется, что вы не той дорогой идете.

А по существу вопроса скажу следующее: дизайнер имеет ограничения и с динамическими запросами, сложными хранимками — работает, это ограничение которое ни как простыми чпособами не обходиться. но у вас всегда остается возможность подправить все руками в .designer.cs что бы явно указать тип данных.

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

но… и тут есть свои игры с partial fnctions

Вам необходимо поставить ISAPI фильтр, который работал бы следующим образом:
IIS будет обрабатывать все входящие соединения, определять virtual host и отдавать обработку ISAPI-фильтру, что полность будет перенаправлять трафик на Apache седящем, скажем на 127.0.0.1:8080

Я сама этого не делала, но посмотрите как Tomcat прикручивается к IISу, думаю этот путь вам поможет.

Не могла устоять.

Team foundation server

Полностью соглашусь с предыдущими ответами, но вот есть пару нюансов:
1. При выборе платформы подумайте о будущем проекта, посмотрите стоимость специалистов в выбраной вами платформы. (Скажем Ruby дороже PHP, Java иногда дороже .NET'а итд)
2. Возможность использовать автоматизированые средства, Object Relation Mapping to Database (ORM). Java & .NET предоставляют UI для работы (не буду вдаваться в подробности кто больше, кто меньше).
3. Оцените сообщество выбраной вами платформы (скажем PHP/JAVA/.NET обладают высококласным и огромным сообществом, чуть позади Ruby/Pylons/Python).

Помощь в проектировании могу оказать, если надоедать не будите. :)

Думаете вы в верном направлении, вот только с сессией чуток ошиблись.
Почему забыли?

Давай-те вспомним причинно-следственную связь: Сессия — это объект кого-то конкретного пользователя (ранее аутентифицированого), соответственно сохраняя данные о пользователе в сессии вы нарушаете причину и следствие.

Предлогаю использовать следующее:
Создать статический класс (думаю это возможно в PHP. В .NET за это отвечает System.Threading.Thread.CurrentPrincipal). И данные текущего пользователя складывать именно в значение свойства статического класса. (Да, есть возможность не санкционированной подмены данных, но с другой стороны можно проводить имперсонализацию (impersonation). А само значение организовать ввиде структуры, которая бы могла быть сериализирована.

Сериализация этой структуры нужно для того, что бы после этого результат шифровать (там есть свои нюансы) и ввиде ОТДЕЛЬНОЙ Cookie складывать на сторону пользователя. А при запросе проверять значение cookie, и востанавливать значение свойства вышеозначеного статического класса.

Подобный подход упростит вам аутентификацию пользователя после перезапуска приложения (ведь сессия — это объект в памяти).

Важные моменты:
1. Не корректное использование шифрования, может привезти к проблемам с безопасностью (значение зашифрованых данных можно сохранить и вторично использовать)
2. Не забыть про синхронизацию данных и учитывать момент того, что во время работы могут быть моменты когда данные рассинхронизированы
(Кто-то в базе уже поменял, а пользователь всё ещё использует старый набор данных. Лечить можно login/logout, если «влоб»).

Будут вопросы, обращайтесь.

Мы на прошлой недели делали тоже самое на базе MS Reporting Service 2008 (тот что вместе с MS SQL Server идёт).
Были проблемы с источником данных на базе, Excel но потом мы обошли ограничения. Думаю вы с ними даже и не встретитесь.

Для тестированя мы используем Microsoft Test Lab 2010 (как-то так) интегрированую в Visual Studio.

Очень удобная штука.

В первую очередь всё зависит от процесса, который вы хотите получить.

В эти выходные обменивалась опытом с коллегами, и для себя вынесла следующее:
При однотипной работе, однотипных проектах или поддержанию давно сущестующего не плохо подходит Scrum,
Для областей которые комманде мало известны или имеют много важных особенностей (а другие бывают?) удобнее использовать CMMI

И следовательно из выше сказанного подбирать нужно под ваш процесс, а не тот у кого кнопочки более вебдванольные.

P.S. Мы используем для обоих процессов Team Foundation Server (иногда с изменёнными шаблонами)