Porównaj ceny domen i usług IT, sprzedawców z całego świata

VS 2017: opcja debugowania zabezpieczeń jest zainstalowana, ale wymaga procesu hostingu programu Visual Studio, który nie jest dostępny


Moje rozwiązanie (zawierające kilkanaście projektów) działa dobrze w Visual Studio 2013.
W Visual Studio 2017 mogę otworzyć rozwiązanie i skompilować je.
Ale jeśli zacznę debugować, systematycznie zdobędę ten komunikat o błędzie:

Ustawiono opcję debugowania zabezpieczeń, ale wymaga ona programu Visual Studio
proces hostingu, który nie jest dostępny w tej konfiguracji debugowania. Opcja
debugowanie zabezpieczeń zostanie wyłączone. Tę opcję można ponownie włączyć
strona właściwości zabezpieczeń. Sesja debugowania będzie kontynuowana bez
debugowanie zabezpieczeń

https://i.stack.imgur.com/iWR6l.png
A potem nic się nie dzieje. Nic się nie zaczyna.
Dla informacji jest to rozwiązanie z wieloma projektami startowymi (w tym projekt WPF).

Edit:

wyłączając opcję „Włącz ustawienia zabezpieczeń ClickOnce” na karcie Projekt - & > Właściwości - & > Bezpieczeństwo, to działa.
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Rozwiązał mój problem
https://social.msdn.microsoft. ... 3Dwpf
:

Możliwe, że przypadkowo przerzuciłeś bit do debugowania
z ustawieniami zabezpieczeń ClickOnce. Czy możesz uzyskać właściwości projektu
dla swojej aplikacji przejdź do zakładki „Bezpieczeństwo” i pamiętaj o odznaczeniu tego pola
„Włącz ustawienia zabezpieczeń ClickOnce” lub zaznacz przycisk opcji „To jest pełne
trust application".
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Na wypadek, gdyby pomogło to komuś innemu - mam to samo rozwiązanie scenariuszowe z wieloma uruchomieniami, które obejmuje klienta, który zostanie wdrożony z ClickOnce. Aby rozwiązać problem polegający na tym, że klient nie uruchamia się po wyświetleniu okna dialogowego Ustawienia zabezpieczeń, przeniosłem go w górę listy w oknie dialogowym Uruchom projekty. Jeśli projekt klienta znajduje się powyżej projektu serwera na liście, nie ma błędu, wszystko jest debugowane. Jeśli projekt klienta znajduje się poniżej projektu serwera, pojawia się błąd, a klient nigdy się nie otwiera. Nie jest to tak naprawdę problem ROZWIĄZAJ, ale jest to dla mnie całkowicie adekwatne obejście.
EDYCJA: Aby to obejście było skuteczne, może być konieczne zamknięcie i ponowne otwarcie programu Visual Studio.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Spędziłem kilka godzin próbując zrozumieć to w tym problemie i zdecydował ją.
Przejdź do projektu

-

>

nieruchomości

... >

budować

Usuń zaznaczenie pola wyboru

Prefer 32-bit

https://i.stack.imgur.com/gHEPS.jpg
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

MS usunęło proces hostingu VS w VS2017 - patrz.
https://vslive.com/Blogs/News- ... .aspx
https://vslive.com/Blogs/News- ... .aspx
Z tego powodu zmiana ustawienia EnableSecurityDebugging w niestandardowym pliku projektu na True powoduje po prostu ponowne wyświetlenie okna dialogowego błędu podczas uruchamiania. Kliknięcie przycisku OK w oknie dialogowym zmienia ustawienie pliku niestandardowego z powrotem na Fałsz.
AFAIK nie ma obejścia, chociaż wydaje się, że MS publikuje bardzo częste aktualizacje VS (najnowsze-15.3) Na razie aplikacje ClickOnce. nie można użyć opcji debugowania zabezpieczeń.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Najprawdopodobniej może to być usterka w jakimś pliku konfiguracyjnym. Opcja „Włącz ustawienia zabezpieczeń ClickOnce” była już nieoznaczona w ustawieniach projektu, ale to okno dialogowe pojawiało się przy każdym uruchomieniu aplikacji. Wykonałem następujące czynności, aby pozbyć się tego okna dialogowego:
  • Otwórz stronę projektu -> Ustawienia zabezpieczeń
  • Zaznacz „Włącz ustawienia zabezpieczeń ClickOnce”
  • Odznacz „Włącz ustawienia zabezpieczeń ClickOnce”
  • Zapisz właściwości i ponownie uruchom aplikację

Nieruchomości
https://i.stack.imgur.com/iVn3R.png
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Oto obejście, które pozwoliło mi debugować moją aplikację ClickOnce. w VS2017 bez otrzymania komunikatu o błędzie „Nie można określić tożsamości abonenta” podczas uzyskiwania dostępu do izolowanej pamięci. Obejście powinno również działać w każdej sytuacji, która wymaga ustawienia ustawień zabezpieczeń ClickOnce.
Aby ponownie utworzyć ustawienia, które zostały wcześniej wygenerowane po zaznaczeniu pola wyboru Włącz ustawienia zabezpieczeń ClickOnce na karcie Zabezpieczenia właściwości projektu, wykonaj następujące kroki:
1. Odznacz opcję włączania opcji zabezpieczeń ClickOnce na karcie Zabezpieczenia we właściwościach projektu
2.Dodaj obok telefonu App.Config, jeśli nie jest jeszcze obecny
<runtime>
<NetFx40_LegacySecurityPolicyenabled="true"/>
</runtime>

3. Dodaj łącze do Microsoft.Build.Tasks.v4.0 do swojego projektu
Kod służący do odtworzenia ustawień ClickOnce można przenieść w dowolne miejsce, ale poniższy przykład główna metoda ilustruje ogólną ideę
using System;
using System.Reflection;
using System.Runtime.Hosting;
using System.Security;
using System.Security.Permissions;
using System.Security.Policy;
using System.Windows.Forms;
using Microsoft.Build.Tasks.Deployment.ManifestUtilities;
namespace SecurityDebuggingTest
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false); if (args.Length > 0 && args[0] == "startui")
{
Application.Run(new Form1());
}
else
{
PermissionSet permissions = new PermissionSet(PermissionState.Unrestricted);
string AppName = Assembly.GetEntryAssembly().GetName().Name;
string AppExe = $"{AppName}.exe";
string DebugSecurityZoneURL = $"{AppExe}.manifest";
string AppManifestPath = $"{AppName}.application";
string appType = "win32";
AssemblyIdentity ca = AssemblyIdentity.FromManifest(AppManifestPath);
string appIdentitySubString = $"Version={ca.Version}, Culture={ca.Culture}, PublicKeyToken={ca.PublicKeyToken}, ProcessorArchitecture={ca.ProcessorArchitecture}";
string assemblyIdentity = $"[url=http://tempuri.org/]http://tempuri.org/[/url]{AppManifestPath}#{AppManifestPath}, {appIdentitySubString}/{AppExe}, {appIdentitySubString},Type={appType}";
System.ApplicationIdentity applicationIdentity = new System.ApplicationIdentity(assemblyIdentity); ApplicationTrust appTrust = new ApplicationTrust();
appTrust.DefaultGrantSet = new PolicyStatement(permissions, PolicyStatementAttribute.Nothing);
appTrust.IsApplicationTrustedToRun = true;
appTrust.ApplicationIdentity = applicationIdentity; AppDomainSetup adSetup = new AppDomainSetup
{
ApplicationBase = AppDomain.CurrentDomain.BaseDirectory,
ActivationArguments = new ActivationArguments( ActivationContext.CreatePartialActivationContext( applicationIdentity,
new string[] { AppManifestPath, DebugSecurityZoneURL })
),
ApplicationTrust = appTrust
}; Evidence e = new Evidence();
e.AddHostEvidence(appTrust); AppDomain a = AppDomain.CreateDomain("Internet Security Zone AppDomain", e, adSetup, permissions);
a.ExecuteAssembly(AppExe, e, new string[] { "startui" });
}
}
}
}

Po pierwszym uruchomieniu powyższego kodu może zostać wyświetlony komunikat ostrzegawczy, że proces VS Hosting nie jest dostępny, ale potem ustawienie EnableSecurityDebugging w niestandardowym pliku projektu zostanie ustawione na wartość False, a kod powinien działać normalnie.
Podziękowania dla zespołu Microsoft ClickOnce za pomoc w rozwiązaniu tego obejścia.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Mam inny powód, dla którego ta wiadomość może się pojawić. W moim przypadku podczas testowania klonowania mojego rozwiązania z Gita zauważyłem, że Visual Studio zdecydowało się ustawić platformę aktywnego rozwiązania na „Dowolny procesor”, podczas gdy mój projekt startowy jest wyraźnie nastawiony na „x86”. Spowodowało to, że projekt nie został uruchomiony, gdy uruchomiłem polecenie kompilacji rozwiązania.
Zaznaczenie pola wyboru kompilacji w menedżerze konfiguracji dla tego projektu pozbyło się komunikatu o błędzie.
Na wypadek, gdyby ktoś zapytał, nie pamiętam dokładnie, dlaczego ten projekt jest wyraźnie ukierunkowany na x86.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Po prostu miałem ten sam problem. Preferowany 32-bitowy został wyłączony.
Spojrzałem na weekend i był to bin.

Utworzyłem ścieżkę bin \ debug i ustawiłem ścieżkę wyjściową na tę.
Zdecydowany.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Dla mnie rozwiązaniem było przełączenie się na „Aplikacja jest dostępna również offline” w zakładce publikowania we właściwościach projektu
Wcześniej „Aplikacja jest dostępna tylko online”
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Szybkie rozwiązanie bez wyjaśnienia: uruchomienie aplikacji w konfiguracji „Debugowanie” zatrzymało błąd i pozwoliło na uruchomienie aplikacji.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się