Все записи автора Андрей Бушман

Прокси в AutoCAD

Обновлена утилита по работе с прокси в AutoCAD.

Что нового...

1. CadProxy был переименован в Proxy Tools for AutoCAD (т.е. в Прокси-инструменты для AutoCAD).
2. Теперь это бесплатное программное обеспечение вместо открытого программного обеспечения.
3. Добавлены русская и английская лицензии.
4. Добавлена русская локализация.
5. Для AutoCAD 2009-2011: в процессе загрузки приложения в AutoCAD, родительский каталог приложения будет добавлен в Путь доступа к вспомогательным файлам (если это ещё не было сделано ранее).* Это необходио для работы справочной системы приложения.
6. Для AutoCAD 2009-2011: в реестре будет выполнена регистрация приложения (загрузка по требованию), если это не было сделано ранее.* В виду этого, вызов команды _NETLOAD для этих версий AutoCAD потребуется только один раз.
7. Операция ПРОВЕРИТЬ (_AUDIT) будет выполняться каждый раз перед расчленением или удалением прокси, если команды ВЗПРОКСИ (_XPROXY) или УДПРОКСИ (_RMPROXY) не являются предыдущей выполненной командой. Так же команда ПРОВЕРИТЬ (_AUDIT) будет автоматически выполняться и после работы этих команд.
8. Если файлы меню CUI\CUIX были ранее загружены пользователем в AutoCAD непосредственно из каталога расширения, тогда они будут выгружены, скопированы в Windows-профиль пользователя и затем в AutoCAD будут загружены эти копии.*
9. Изображения в файлах меню CUI\CUIX были заменены. Теперь эти изображения используют ICO формат вместо BMP (новые изображения используют прозрачность).
10. MNR-файлы были удалены из MSI-инсталлятора.
11. MSI-инсталлятор был полностью переписан. Теперь он показывает лицензию, устанавливаемые наборы компонентов, а так же предоставляет фиксированный набор каталогов, в которые может быть выполнена установка приложения.
12. Имеется две версии локализации MSI-установщика: английская и русская.
13. Инсталлятор добавляет пункты меню в Пуск -> Все программы. Локализация этих пунктов меню совпадает с локализацией использованного MSI-инсталлятора.
14. Теперь 32-битная версия MSI-инсталлятора не может использоваться для Windows x64 (ограничение добавлено намеренно).
15. Теперь расширение может быть установлено как с административными правами, так и без них. Это зависит от выбора, который сделает пользователь в процессе установки приложения.
16. Файл справки полностью переписан.
17. Исправлены некоторые ошибки в программном коде.

* - Проверка будет выполняться каждый раз при загрузке приложения в AutoCAD.

Пользовательское меню:



 Меню в Пуск -> Все программы:


 Дополнительная информация, размещаемая в реестре:


Возможность выбрать целевой каталог установки:


Локализованная справка:




Прокси в AutoCAD

Обновлена утилита по работе с прокси в AutoCAD.

Что нового...

1. CadProxy был переименован в Proxy Tools for AutoCAD (т.е. в Прокси-инструменты для AutoCAD).
2. Теперь это бесплатное программное обеспечение вместо открытого программного обеспечения.
3. Добавлены русская и английская лицензии.
4. Добавлена русская локализация.
5. Для AutoCAD 2009-2011: в процессе загрузки приложения в AutoCAD, родительский каталог приложения будет добавлен в Путь доступа к вспомогательным файлам (если это ещё не было сделано ранее).* Это необходио для работы справочной системы приложения.
6. Для AutoCAD 2009-2011: в реестре будет выполнена регистрация приложения (загрузка по требованию), если это не было сделано ранее.* В виду этого, вызов команды _NETLOAD для этих версий AutoCAD потребуется только один раз.
7. Операция ПРОВЕРИТЬ (_AUDIT) будет выполняться каждый раз перед расчленением или удалением прокси, если команды ВЗПРОКСИ (_XPROXY) или УДПРОКСИ (_RMPROXY) не являются предыдущей выполненной командой. Так же команда ПРОВЕРИТЬ (_AUDIT) будет автоматически выполняться и после работы этих команд.
8. Если файлы меню CUICUIX были ранее загружены пользователем в AutoCAD непосредственно из каталога расширения, тогда они будут выгружены, скопированы в Windows-профиль пользователя и затем в AutoCAD будут загружены эти копии.*
9. Изображения в файлах меню CUICUIX были заменены. Теперь эти изображения используют ICO формат вместо BMP (новые изображения используют прозрачность).
10. MNR-файлы были удалены из MSI-инсталлятора.
11. MSI-инсталлятор был полностью переписан. Теперь он показывает лицензию, устанавливаемые наборы компонентов, а так же предоставляет фиксированный набор каталогов, в которые может быть выполнена установка приложения.
12. Имеется две версии локализации MSI-установщика: английская и русская.
13. Инсталлятор добавляет пункты меню в Пуск -> Все программы. Локализация этих пунктов меню совпадает с локализацией использованного MSI-инсталлятора.
14. Теперь 32-битная версия MSI-инсталлятора не может использоваться для Windows x64 (ограничение добавлено намеренно).
15. Теперь расширение может быть установлено как с административными правами, так и без них. Это зависит от выбора, который сделает пользователь в процессе установки приложения.
16. Файл справки полностью переписан.
17. Исправлены некоторые ошибки в программном коде.

* - Проверка будет выполняться каждый раз при загрузке приложения в AutoCAD.

Пользовательское меню:



 Меню в Пуск -> Все программы:


 Дополнительная информация, размещаемая в реестре:


Возможность выбрать целевой каталог установки:


Локализованная справка:




Изменение серийного номера для MS Office 2016

Порой, производя очередную активацию MS Office, можно получить сообщение о том, что лимит количества активаций с этим ключом уже исчерпан... В этом случае можно выполнить активацию переписав ключ новым значением. Возникает вопрос: как заменить ранее указанный ключ продукта на более новый?


Ответ на обозначенный вопрос я нашёл на форуме Майкрософт (спасибо Faruk Ekiz). Копирую ответ Faruk Ekiz в своей записи в качестве шпаргалки, дабы позднее всегда мог быстро находить его.


1. Open a command prompt. For instance via:
  • Start-> All Programs-> Accessories-> Command Prompt
  • Windows XP
    Start-> Run: cmd
  • Windows Vista, Windows 7 and Windows 8
    Start-> type: cmd
2. In the command prompt, type the following:
  • Office 2016 (32-bit) on a 32-bit version of Windows
    cscript "C:Program FilesMicrosoft OfficeOffice16OSPP.VBS" /dstatus
  • Office 2016 (32-bit) on a 64-bit version of Windows
    cscript "C:Program Files (x86)Microsoft OfficeOffice16OSPP.VBS" /dstatus
  • Office 2016 (64-bit) on a 64-bit version of Windows
    cscript "C:Program FilesMicrosoft OfficeOffice16OSPP.VBS" /dstatus
3. You should now get a screen with some license details such as the license name, type and the last 5 characters of the Product Key.

Image


You can also change the Product Key via the OSPP.VBS script. Instead of using the /dstatus switch, you must use the /inpkey:value switch where you should replace value for your Product Key.

For example:
cscript "C:Program Files (x86)Microsoft OfficeOffice16ospp.vbs" /inpkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Изменение серийного номера для MS Office 2016

Порой, производя очередную активацию MS Office, можно получить сообщение о том, что лимит количества активаций с этим ключом уже исчерпан... В этом случае можно выполнить активацию переписав ключ новым значением. Возникает вопрос: как заменить ранее указанный ключ продукта на более новый?


Ответ на обозначенный вопрос я нашёл на форуме Майкрософт (спасибо Faruk Ekiz). Копирую ответ Faruk Ekiz в своей записи в качестве шпаргалки, дабы позднее всегда мог быстро находить его.


1. Open a command prompt. For instance via:
  • Start-> All Programs-> Accessories-> Command Prompt
  • Windows XP
    Start-> Run: cmd
  • Windows Vista, Windows 7 and Windows 8
    Start-> type: cmd
2. In the command prompt, type the following:
  • Office 2016 (32-bit) on a 32-bit version of Windows
    cscript "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" /dstatus
  • Office 2016 (32-bit) on a 64-bit version of Windows
    cscript "C:\Program Files (x86)\Microsoft Office\Office16\OSPP.VBS" /dstatus
  • Office 2016 (64-bit) on a 64-bit version of Windows
    cscript "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" /dstatus
3. You should now get a screen with some license details such as the license name, type and the last 5 characters of the Product Key.

Image


You can also change the Product Key via the OSPP.VBS script. Instead of using the /dstatus switch, you must use the /inpkey:value switch where you should replace value for your Product Key.

For example:
cscript "C:\Program Files (x86)\Microsoft Office\Office16\ospp.vbs" /inpkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

ODA обновила свой сайт

Компания ODA обновила внешний вид своего сайта. Теперь он смотрится гораздо лучше. Кроме того, в обновлённой версии сайта появилась группа Blog, с категорией Guide (помимо прочих), что даёт некоторую надежду на то, что в этой категории в дальнейшем будут появляться записи.

ODA обновила свой сайт

Компания ODA обновила внешний вид своего сайта. Теперь он смотрится гораздо лучше. Кроме того, в обновлённой версии сайта появилась группа Blog, с категорией Guide (помимо прочих), что даёт некоторую надежду на то, что в этой категории в дальнейшем будут появляться записи.

Импорт конфигурационных настроек сервисами и клиентами WCF

В некоторых случаях службы и клиенты удобно реализовывать в виде отдельных DLL, которые затем могут быть использованы различными приложениями. Например: MyService.dll и MyClient.dll. Предполагается, что они будут находиться в подкаталогах ./Extensions/MyExtensionName/ хостовых приложений, дабы при необходимости оный контент всегда можно было бы просто удалить даже вручную, не зацепив при этом случайно ресурсы основного приложения.

Однако, будучи подгруженными в хостовое приложение они, как и любые другие DLL, по умолчанию будут искать свои настройки в составе конфигурационного файла этого приложения. Всё же мне бы не хотелось в чужой config-файл вносить правки, необходимые для работы моих сервисов или клиентов, ну или хотелось бы, по крайней мере, минимизировать объём таких корректировок настолько, насколько это возможно... На мой взгляд, предпочтительным способом была бы возможность сохранения нужных мне настроек в отдельных конфигурационных файлах, находящихся рядом с соответствующей DLL моего сервиса или клиента, т.е. в файлах MyService.dll.config и MyClient.dll.config.

Экспорт конфигурационных настроек на стороне сервиса
Начиная с .NET 4.5 в классе реализации сервиса можно определить метод Configure со следующей сигнатурой:

public static void Configure(ServiceConfiguration config)

Этот метод будет вызван WCF перед началом использования нашей службы. В нём можно выполнить загрузку конфигурационных настроек из внешнего файла, например так:

public static void Configure(ServiceConfiguration config) {
    ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
    configMap.ExeConfigFilename = typeof(MyService).Assembly.Location + ".config";
    Configuration dll_config = ConfigurationManager.OpenMappedExeConfiguration(configMap,
        ConfigurationUserLevel.None);
    config.LoadFromConfiguration(dll_config);
}

Однако в бочке мёда имеется и ложка дёгтя: в процессе импорта настроек WCF будет игнорировать все базовые адреса, обозначенные в импортируемом файле. Соответственно, либо эти базовые адреса нужно будет предварительно указать в конфигурационном файле самого хостового приложения (чего делать не очень хотелось бы, хотя это и не смертельно), либо в составе импортируемого файла настроек для конечных точек подключения и для метаданных использовать только полные адреса. Какой из вариантов выбрать - это уже нужно будет смотреть по ситуации.

Например, если расширение хранится в каталоге %AppData%/CompanyName/ApplicationName/Extensions/MyExtensionName/ с тем, чтобы предоставлять пользователю возможность править конфигурационные настройки или вовсе удалять расширение, то нужным вариантом будет второй.

А если пользователь не имеет административных прав и расширение хранится в каталоге %ProgramFiles%/CompanyName/ApplicationName/Extensions/MyExtensionName/, то в данном случае вариант использования - это дело вкуса администратора.

Экспорт конфигурационных настроек на стороне клиента
На стороне клиента использовать метод Configure в коде наших прокси не получится, но начиная с WCF 4.0 нам в помощь появился класс ConfigurationChannelFactory. Его можно создать в конструкторе создаваемого нами прокси  и использовать в процессе работы например так:

[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class Drawing : IDisposable, IDrawing {

    IDrawing Channel;
    ConfigurationChannelFactory<IDrawing> channelFactory;

    public void Open() {
        if (channelFactory.State != CommunicationState.Opened &&
            channelFactory.State != CommunicationState.Opening)
            channelFactory.Open();
    }

    public void Close() {
        if (channelFactory.State == CommunicationState.Opened)
            channelFactory.Close();
    }

    public CommunicationState State
    {
        get { return channelFactory.State; }
    }

    public Drawing(string endpointName) {
        ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
        configMap.ExeConfigFilename = typeof(Drawing).Assembly.Location + ".config";
        Configuration dll_config = ConfigurationManager.OpenMappedExeConfiguration(configMap,
            ConfigurationUserLevel.None);
        channelFactory =
            new ConfigurationChannelFactory<IDrawing>(endpointName, dll_config, null);
        Channel = channelFactory.CreateChannel();
    }

    public void Dispose() {
        if (channelFactory != null&& channelFactory.State == CommunicationState.Opened)
            channelFactory.Close();
    }

    // here is other members...   
}
Обратите внимание на то, что в процессе реализации нужного нам прокси мы обошлись без наследования от класса ClientBase.

Ссылки:

Импорт конфигурационных настроек сервисами и клиентами WCF

В некоторых случаях службы и клиенты удобно реализовывать в виде отдельных DLL, которые затем могут быть использованы различными приложениями. Например: MyService.dll и MyClient.dll. Предполагается, что они будут находиться в подкаталогах ./Extensions/MyExtensionName/ хостовых приложений, дабы при необходимости оный контент всегда можно было бы просто удалить даже вручную, не зацепив при этом случайно ресурсы основного приложения.

Однако, будучи подгруженными в хостовое приложение они, как и любые другие DLL, по умолчанию будут искать свои настройки в составе конфигурационного файла этого приложения. Всё же мне бы не хотелось в чужой config-файл вносить правки, необходимые для работы моих сервисов или клиентов, ну или хотелось бы, по крайней мере, минимизировать объём таких корректировок настолько, насколько это возможно... На мой взгляд, предпочтительным способом была бы возможность сохранения нужных мне настроек в отдельных конфигурационных файлах, находящихся рядом с соответствующей DLL моего сервиса или клиента, т.е. в файлах MyService.dll.config и MyClient.dll.config.

Экспорт конфигурационных настроек на стороне сервиса
Начиная с .NET 4.5 в классе реализации сервиса можно определить метод Configure со следующей сигнатурой:

public static void Configure(ServiceConfiguration config)

Этот метод будет вызван WCF перед началом использования нашей службы. В нём можно выполнить загрузку конфигурационных настроек из внешнего файла, например так:

public static void Configure(ServiceConfiguration config) {
    ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
    configMap.ExeConfigFilename = typeof(MyService).Assembly.Location + ".config";
    Configuration dll_config = ConfigurationManager.OpenMappedExeConfiguration(configMap,
        ConfigurationUserLevel.None);
    config.LoadFromConfiguration(dll_config);
}

Однако в бочке мёда имеется и ложка дёгтя: в процессе импорта настроек WCF будет игнорировать все базовые адреса, обозначенные в импортируемом файле. Соответственно, либо эти базовые адреса нужно будет предварительно указать в конфигурационном файле самого хостового приложения (чего делать не очень хотелось бы, хотя это и не смертельно), либо в составе импортируемого файла настроек для конечных точек подключения и для метаданных использовать только полные адреса. Какой из вариантов выбрать - это уже нужно будет смотреть по ситуации.

Например, если расширение хранится в каталоге %AppData%/CompanyName/ApplicationName/Extensions/MyExtensionName/ с тем, чтобы предоставлять пользователю возможность править конфигурационные настройки или вовсе удалять расширение, то нужным вариантом будет второй.

А если пользователь не имеет административных прав и расширение хранится в каталоге %ProgramFiles%/CompanyName/ApplicationName/Extensions/MyExtensionName/, то в данном случае вариант использования - это дело вкуса администратора.

Экспорт конфигурационных настроек на стороне клиента
На стороне клиента использовать метод Configure в коде наших прокси не получится, но начиная с WCF 4.0 нам в помощь появился класс ConfigurationChannelFactory. Его можно создать в конструкторе создаваемого нами прокси  и использовать в процессе работы например так:

[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class Drawing : IDisposable, IDrawing {

    IDrawing Channel;
    ConfigurationChannelFactory<IDrawing> channelFactory;

    public void Open() {
        if (channelFactory.State != CommunicationState.Opened &&
            channelFactory.State != CommunicationState.Opening)
            channelFactory.Open();
    }

    public void Close() {
        if (channelFactory.State == CommunicationState.Opened)
            channelFactory.Close();
    }

    public CommunicationState State
    {
        get { return channelFactory.State; }
    }

    public Drawing(string endpointName) {
        ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
        configMap.ExeConfigFilename = typeof(Drawing).Assembly.Location + ".config";
        Configuration dll_config = ConfigurationManager.OpenMappedExeConfiguration(configMap,
            ConfigurationUserLevel.None);
        channelFactory =
            new ConfigurationChannelFactory<IDrawing>(endpointName, dll_config, null);
        Channel = channelFactory.CreateChannel();
    }

    public void Dispose() {
        if (channelFactory != null&& channelFactory.State == CommunicationState.Opened)
            channelFactory.Close();
    }

    // here is other members...   
}
Обратите внимание на то, что в процессе реализации нужного нам прокси мы обошлись без наследования от класса ClientBase.

Ссылки:

Об использовании событий pre-build и post-build в Visual Studio

В некоторых проектах, создаваемых при помощи Visual Studo, возникает необходимость выполнения различного рода дополнительных операций в pre-build [и | или] post-build.

Если исходный код проекта находится в сети, а не на локальном диске, то открывать его следует в Visual Studio через предварительно подключенный сетевой диск. Т.е. например, если исходный код проекта находится в каталоге "\\hyprostr\dfs\groups\developers\src\DwgSaveAs\", то следует предварительно создать сетевой диск при помощи команды NET ADD:

net add Y: "\\hyprostr\dfs\groups\developers"

После этого, открывать в IDE проект, находящийся в сети, всегда следует путём указания каталога "Y:\src\DwgSaveAs\", вместо его сетевого имени "\\hyprostr\dfs\groups\developers\src\DwgSaveAs". В этом случае значения переменных ProjectDir, TargetDir и т.п. будут так же содержать значения, начинающиеся с "Y:\", а не с "\\hyprostr\". Это позволит в pre-build и post-build использовать команды такие как COPY, т.е. такие, которые обычно не могут работать с UNC-путями.

Предположим, что в событии post-build нашего проекта размещена такая команда:

COPY /Y "$(ProjectDir)teigha_vc11_amd64dll\*" "$(TargetDir)*"

Если проект будет открыт в IDE с использованием сетевого пути ("\\hyprostr\..."), а не сетевого диска "Y:\...", то попытка выполнить операцию, обозначенную в post-build будет неудачной. Если же проект будет открыть с использованием сетевого диска, то обозначенная в команде операция будет выполнена успешно.

Циклы в pre-build и post-build

Обозначенная выше команда, размещённая в post-build, может оказаться нецелесообразной в использовании, если выполняется копирование большого количества файлов. В подобных случаях процесс сборки проекта может занимать времени больше, чем нам бы того хотелось. Да и вообще, каждый раз выполнять копирование файлов, не подвергавшихся изменению, не целесообразно...

Порой нам нужно копировать только такие файлы, которых ещё нет целевом каталоге. Например, это могут быть файлы библиотек сторонних разработчиков. Чтобы копировать только отсутствующие в целевом каталоге файлы, в нашем post-build предыдущий вариант команды можно заменить таким:

For %%F In ("$(ProjectDir)teigha_vc11_amd64dll\*.*") Do If Not Exist "$(TargetDir)%%~nxF" Copy "%%F" "$(TargetDir)%%~nxF"

Внимание!
Обратите внимание на то, что все символы % в данном случае должны быть продублированы. В этом нет необходимости в BAT-файлах, но при использовании подобных выражений в составе pre-build или post-build проектов Visual Studio такая потребность имеется.

Примечание
Несмотря на то, что решения открываемые через сетевой диск отображаются в группе Recent вкладки Start Page, тем не менее Visual Studio 2015 Update 2 не умеет их открывать через соответствующую ссылку, если пытаться сделать это сразу после запуска IDE. При попытке сделать это, появляется такое окошко:


Чтобы открыть решение через сетевой диск, сразу после запуска Visual Studio, придётся выбирать пункт Open Project на вкладке Start Page, или же сделать это через меню File -> Open Project/Solution. Кроме того, работает и способ открытия sln-файла решения (из сетевого диска) в Проводнике Windows.

Если затем закрыть решение, не завершая при этом работу IDE (т.е. при помощи пункта меню  File -> Close Solution), то соответствующая ссылка на решение в группе Recent будет работать. Причём работать будет и в том случае, если выбрав пункт меню File -> Open Project/Solution затем перейти в каталог решения и нажать кнопку Cancel - после этого, соответствующая ссылка в Recent сможет открывать решение. Правда всё это работает только до перезапуска IDE...


Об использовании событий pre-build и post-build в Visual Studio

В некоторых проектах, создаваемых при помощи Visual Studo, возникает необходимость выполнения различного рода дополнительных операций в pre-build [и | или] post-build.

Если исходный код проекта находится в сети, а не на локальном диске, то открывать его следует в Visual Studio через предварительно подключенный сетевой диск. Т.е. например, если исходный код проекта находится в каталоге "\\hyprostr\dfs\groups\developers\src\DwgSaveAs\", то следует предварительно создать сетевой диск при помощи команды NET ADD:

net add Y: "\\hyprostr\dfs\groups\developers"

После этого, открывать в IDE проект, находящийся в сети, всегда следует путём указания каталога "Y:\src\DwgSaveAs\", вместо его сетевого имени "\\hyprostr\dfs\groups\developers\src\DwgSaveAs". В этом случае значения переменных ProjectDir, TargetDir и т.п. будут так же содержать значения, начинающиеся с "Y:\", а не с "\\hyprostr\". Это позволит в pre-build и post-build использовать команды такие как COPY, т.е. такие, которые обычно не могут работать с UNC-путями.

Предположим, что в событии post-build нашего проекта размещена такая команда:

COPY /Y "$(ProjectDir)teigha_vc11_amd64dll\*" "$(TargetDir)*"

Если проект будет открыт в IDE с использованием сетевого пути ("\\hyprostr\..."), а не сетевого диска "Y:\...", то попытка выполнить операцию, обозначенную в post-build будет неудачной. Если же проект будет открыть с использованием сетевого диска, то обозначенная в команде операция будет выполнена успешно.

Циклы в pre-build и post-build

Обозначенная выше команда, размещённая в post-build, может оказаться нецелесообразной в использовании, если выполняется копирование большого количества файлов. В подобных случаях процесс сборки проекта может занимать времени больше, чем нам бы того хотелось. Да и вообще, каждый раз выполнять копирование файлов, не подвергавшихся изменению, не целесообразно...

Порой нам нужно копировать только такие файлы, которых ещё нет целевом каталоге. Например, это могут быть файлы библиотек сторонних разработчиков. Чтобы копировать только отсутствующие в целевом каталоге файлы, в нашем post-build предыдущий вариант команды можно заменить таким:

For %%F In ("$(ProjectDir)teigha_vc11_amd64dll\*.*") Do If Not Exist "$(TargetDir)%%~nxF" Copy "%%F" "$(TargetDir)%%~nxF"

Внимание!
Обратите внимание на то, что все символы % в данном случае должны быть продублированы. В этом нет необходимости в BAT-файлах, но при использовании подобных выражений в составе pre-build или post-build проектов Visual Studio такая потребность имеется.

Примечание
Несмотря на то, что решения открываемые через сетевой диск отображаются в группе Recent вкладки Start Page, тем не менее Visual Studio 2015 Update 2 не умеет их открывать через соответствующую ссылку, если пытаться сделать это сразу после запуска IDE. При попытке сделать это, появляется такое окошко:


Чтобы открыть решение через сетевой диск, сразу после запуска Visual Studio, придётся выбирать пункт Open Project на вкладке Start Page, или же сделать это через меню File -> Open Project/Solution. Кроме того, работает и способ открытия sln-файла решения (из сетевого диска) в Проводнике Windows.

Если затем закрыть решение, не завершая при этом работу IDE (т.е. при помощи пункта меню  File -> Close Solution), то соответствующая ссылка на решение в группе Recent будет работать. Причём работать будет и в том случае, если выбрав пункт меню File -> Open Project/Solution затем перейти в каталог решения и нажать кнопку Cancel - после этого, соответствующая ссылка в Recent сможет открывать решение. Правда всё это работает только до перезапуска IDE...