Хранение проектов Visual Studio на сетевом диске

Ну, мой вопрос состоял бы в том, почему Вы спрашиваете это. Разве это не работает при хранении его на сетевом диске? Я не попробовал это сам, и одна проблема, которую я мог предположить, будет состоять в том, что код.NET, работающий от сетевого диска (т.е. из bin\Debug каталога, также расположенного на сетевом диске), работал бы в режиме песочницы, если Вы не бездельничаете с CASPOL (или используйте 3,5 SP1, которые я слышу, удалил то препятствие).

, Если у Вас есть определенные проблемы, спросите о них. Никогда не спрашивайте, "Почему делает X не работа?".

Вы не говорите, всего ли Вы - один человек или несколько человек, получающих доступ к тому же удаленному диску, но я предполагаю, что Вы всего один для каждого сетевого каталога. Это корректно? В противном случае не нет никакого лейкопластыря. Получите управление версиями, положите обратно файлы к локальному диску.

"Как я могу заставить это работать?" У Вас есть пара выбора:

Выбор A: 1. Положите обратно все файлы к своему локальному жесткому диску 2. Реализуйте некоторый тип программного обеспечения для резервного копирования на Вашей машине 3. Test сказал решение для резервного копирования 4. продолжите кодировать

Выбор B: 1. Получите копию одного из СВОБОДНЫХ продуктов управления исходным кодом и реализуйте его. 2. Удостоверьтесь, что это сохраняется 3. Test это

Выбор C: Используйте один из многих доступных репозиториев управления исходным кодом ОНЛАЙН. Google, SourceForge, CodePlex, что-то.

Если я понимаю Вас правильно, Ваши файлы проекта Visual Studio хранятся на сетевом диске, и Вы выполняете их оттуда. Это - то, что я делаю и не имею никакими проблемами. Необходимо будет удостовериться, что Вы установили политику безопасности. Можно использовать Caspol, чтобы сделать это, или с помощью меню административных средств панели управления.

У Вас есть какие-либо определенные проблемы?

, Если Вы позволяете больше чем одному человеку открывать решение, Ваша первая проблема будет состоять в том, что.NCB файл (Intellisense) будет заблокирован исключительно, и только один пользователь будет в состоянии просмотреть дерево класса. И конечно у Вас есть потенциал для изменений одного пользователя для перезаписи изменений другого пользователя.

Не делайте этого. Если у Вас есть управление исходным кодом (управление версиями), Вы не хотите свои файлы на сетевом диске. Это полностью обходит все, чего Вы хотите достигнуть при помощи управления исходным кодом, потому что, как только Ваши файлы находятся на сетевом диске, любой может изменить их.... даже, в то время как Вы в настоящее время разрабатываете свой проект. Ka-boooom!

пз: это походит на типичный случай сверхразработки мне.

Я не рекомендовал бы делать это, если Вы имеете (или даже если Вы не имеете), несколько человек, которые работают над проектами. Вы просто напрашиваетесь на неприятности.

, Если Вы - единственный, работающий над ним, с другой стороны, Вы избежите большой части проблемы. Производительность идет в из окна, все же. До, как заставить его работать, Вы просто открываете файл решения из VS. Вы, вероятно, столкнетесь с проблемами безопасности, но можете исправить то использование CASPOL. Поскольку я сказал, тем не менее, что производительность будет ужасной. Снова, не рекомендуемый вообще.

Делают себе и Вашей команде одолжение и устанавливают SVN или некоторую другую форму управления исходным кодом и помещают код там как можно скорее.

РЕДАКТИРОВАНИЕ: я частично отрекусь от своих комментариев. Bob King объясняет ниже причины, они выполняют проекты VS от сетевого диска, и она имеет смысл. Я сказал бы, если Вы не делаете его по определенной причине как Bob, избегаете его. Иначе получите своих уток подряд перед установкой такой среды разработки.

Следует предупредить, что некоторые функции Visual Studio не будут работать с сетевым диском.

Например, mdf-файл пользовательского экземпляра SQL Express должен находиться на локальном диске.

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

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

У меня есть копия VB 2008 (недавно обновленная с VB6). Если я сохраню свои решения на резервном сетевом диске, то он никогда не запустит ни одной вещи. Он выдает ошибки «частично доверенный вызывающий» для доступа к модулю, даже если в сборке установлено «allowparhibitedtrustedcallers». Если я сохраню файлы на моем (без резервной копии) C :, тогда он будет работать замечательно, пока я не помещу его на общий диск для всех, и я снова вернусь к своей проблеме.

Это небольшая просьба. Я просто хочу иметь возможность разместить решение и исполняемый файл на общем диске и запустить его без абсурдной чепухи о безопасности. Мне не нужно было запихивать всю свою работу в файлы форм.

-Редактировать: Я обнаружил проблему, почему он игнорировал команду AllowPartialllyTrustedCallers. Я пытаюсь сослаться на ADODB, который не позволяет частично доверять. Итак, никакой сетевой исполняемый файл не может получить доступ к базе данных? Что в любом случае имеет Microsoft против интрасетей?