Я разрабатываю изолированный Shell , который обслуживает "дизайнеров / специальных создателей контента", выполняющих конкретные задачи, используя Shell. Поскольку они работают с файлами,они должны иметь возможность использовать TFS для управления версиями. Это в основном связано с тем, что разработчики также будут работать с теми же файлами из TFS, но с использованием Visual studio 2008.

После просмотра и поиска я все еще не мог найти команду Explorer, чтобы быть доступным для Shell. Спрашивая на MSDN форумах, приведите меня к ответу, что "this is not supported yet in the Isolated Shell". Ну, тогда весь смысл отдавать shell не оправдан, если вы хотите использовать систему управления версиями для своих файлов. Идея состоит не в том, чтобы воссоздать все и разработать инструмент windows и т. д. с использованием поставщика TFS API.

В книге Visual Studio Extensibility book by Keyven Nayyeri есть пример, который только заходит так далеко в эту проблему добавления поставщика sc.

Кто - нибудь работал над разработкой Visual Studio 2008 Isolated Shell applications/environment? пожалуйста, предоставьте комментарии, вопросы-все, что вы должны поделиться, кроме следующих тем, в которых я уже участвовал.

Темы с форумов MSDN:

• Команда Explorer для изолированных Shell
• Можно ли использовать команду Explorer в VS Shell изолированных?

Спасибо за ваш ответ. Да, вы правы, мы приобретем CALs для пользователей, не покупая им Visual Studio, это направление, которое мы будем принимать.

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

Я имею в виду, у меня есть пользователь, он устанавливает мое приложение VS Shell, у него нет командной системы VStudio на его машине. Теперь, если я приобрету CAL для TFS и установлю Team Explorer, как вы думаете, он будет автоматически доступен в приложении VS Shell?

Есть идеи? вы работали над тем, чтобы это произошло?

Спасибо

У меня есть веб-сервис ASP.NET с такими функциями, как:

[WebService(Namespace = "http://internalservice.net/messageprocessing")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ToolboxItem(false)]
public class ProvisioningService : WebService
{
    [WebMethod]
    public XmlDocument ProcessMessage(XmlDocument message)
    {
        // ... do stuff
    }
}

Я вызываю веб-службу из ASP, используя что-то вроде:

provWSDL = "http://servername:12011/MessageProcessor.asmx?wsdl"
Set service = CreateObject("MSSOAP.SoapClient30")
service.ClientProperty("ServerHTTPRequest") = True
Call service.MSSoapInit(provWSDL)

xmlMessage = "<request><task>....various xml</task></request>"
result = service.ProcessMessage(xmlMessage)

Проблема, с которой я сталкиваюсь, заключается в том, что когда XML достигает метода ProcessMessage, веб-служба plumbing попутно добавила пространство имен по умолчанию. т. е. если я установлю точку останова внутри ProcessMessage (сообщение XmlDocument), я увижу:

<request xmlns="http://internalservice.net/messageprocessing">
  <task>....various xml</task> 
</request>

Когда я захватываю пакеты по проводу, я вижу, что XML, отправленный инструментарием SOAP, немного отличается от того, что отправлено клиентом .NET WS. Набор инструментов SOAP отправляет:

<SOAP-ENV:Envelope 
    xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema" 
    xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/" 
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Body>
        <ProcessMessage xmlns="http://internalservice.net/messageprocessing">
            <message xmlns:SOAPSDK4="http://internalservice.net/messageprocessing">
                <request>
                    <task>...stuff to do</task>
                </request>
            </message>
        </ProcessMessage>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Если клиент отправляет .NET:

<soap:Envelope 
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soap:Body>
        <ProcessMessage xmlns="http://internalservice.net/messageprocessing">
            <message>
                <request xmlns="">
                    <task>...stuff to do</task>
                </request>
            </message>
        </ProcessMessage>
    </soap:Body>
</soap:Envelope>

Прошло так много времени с тех пор, как я использовал инструментарий ASP/SOAP для вызова веб-сервисов .NET, что я не могу вспомнить все умные tricks/SOAP-fu, которые я использовал, чтобы обойти подобные вещи.

Есть какие-нибудь идеи? Одним из решений является создание вызываемого COM .NET прокси, который принимает XML как строковый парам и вызывает WS от моего имени, но это дополнительный уровень сложности/работы, которую я надеялся не делать.

При настройке CruiseControl я добавил блок buildpublisher в задачи издателя:

<buildpublisher>
  <sourceDir>C:\MyBuild\</sourceDir>
  <publishDir>C:\MyBuildPublished\</publishDir>
  <alwaysPublish>false</alwaysPublish>
</buildpublisher> 

Это работает, но он копирует все содержимое файла сборки, я только хочу скопировать страницы DLL и .aspx, мне не нужен исходный код для публикации.

Кто-нибудь знает способ фильтровать это, или мне нужно настроить задачу для запуска скрипта RoboCopy вместо этого?