My solution (which contains a dozen projects) works perfectly in Visual Studio 2013.
In Visual Studio 2017, I can open the solution and compile it.
But if I start the debug, I systematically get this error message:
The security debugging option is set but it requires the Visual Studio
hosting process which is unavailable in this debugging configuration.The
security debugging option will be disabled. This option may be re-enabled in
the Security property page. The debugging session will continue without
security debugging
And then, nothing happens. Nothing starts.
For information, this is a solution with multiple startup projects (including a WPF project).
Edit :
By disabling the option "Enable ClickOnce security settings" under Project -> Properties -> Security tab, it works.
This solved my issue:
Most likely, you have accidentally gotten the bit flipped to debug
with ClickOnce security settings. Can you get the project properties
for your app, go to the "Security" tab, and make sure to uncheck
"Enable ClickOnce Security settings" or check the "This is a full
trust application" radio button.
In case it helps anyone else - I have the same scenario - a multiple startup solution that includes a client that will be deployed with ClickOnce. To eliminate the problem that the client doesn't start after getting the Security Settings dialog, I moved it higher in the list in the startup projects dialog. If the client project is above the server project in the list, no error, everything debugs. If the client project is below the server project, then I get the error and the client never opens. This doesn't exactly SOLVE the problem but is a perfectly adequate workaround for me.
EDIT: You might need to close and reopen your Visual Studio for this workaround to be effective.
I spent hours trying to figure out the issue, this resolved it.
Go to Projct > Properties... > Build
Uncheck the checkbox Prefer 32-bit
MS have removed the VS hosting process in VS2017 - see
https://vslive.com/Blogs/News-and-Tips/2017/02/Debugging-Visual-Studio-2017-aims-to-speed-up-your-least-favorite-job.aspx
Because of this changing the EnableSecurityDebugging setting in the project user file to True simply results in the Error dialog appearing again at run-time.Clicking on OK in the dialog changes the user file setting back to False.
AFAIK there is no workaround although MS seem to be posting very frequent VS updates (latest is 15.3) In the meantime ClickOnce apps. will be unable to use the security debugging option.
This could likely be a glitch in some configuration file. The "Enable ClickOnce security settings" was already unmarked in the project settings but still this dialogue appeared every time the application was started. I did the following to get rid of this dialogue:
Open the project->security setting page
Mark "Enable ClickOnce security settings"
Unmark "Enable ClickOnce security settings"
Save the properties and start the application again
Properties
Here's a workaround that enabled me to debug my ClickOnce app. in VS2017 without getting the error message "Unable to determine identity of caller" when accessing Isolated Storage. The workaround should also work in any situation that requires the ClickOnce security settings.
To recreate the settings that were previously generated when the Enable ClickOnce security settings on the Security tab of the project's properties was checked, do the following:
1.Uncheck Enable ClickOnce security settings on the Security tab of your project's properties
2.Add the following to your App.Config file if not already present
<runtime>
<NetFx40_LegacySecurityPolicyenabled="true"/>
</runtime>
3.Add a reference to Microsoft.Build.Tasks.v4.0 to your project
The code to recreate the ClickOnce settings can go anywhere, but the following sample Main method illustrates the general idea
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 = $"http://tempuri.org/{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" });
}
}
}
}
You may see the warning message about the VS Hosting process being unavailable when you first run the above code but thereafter the EnableSecurityDebugging setting in your project's user file will have been set to False and the code should run as normal.
Thanks to Microsoft's ClickOnce team for their help on this workaround.
I have yet another cause for why this message may come up. In my case, while testing cloning my solution from Git, I noticed that Visual Studio decided to set the Active solution platform to "Any CPU", whereas my startup project is explicitly targetting "x86". This caused the startup project to not build when I ran the build solution command.
Checking the Build box in the Configuration Manager for that project got rid of the error message.
In case anyone asks, I don't remember exactly why that one project is explicitly targetting x86.
I just had the same issue. Prefer 32-Bit was disabled.
I looked in the Output Path and it was bin\Release.
I created a bin\debug path and set the Output Path to this.
Resolved.
For me the solution was to switch to "The application is available offline as well" in Publish tab of project properties
Before I had "The application is available online only"
My issue seemed to be associated with the folder that the solution was in. My DEV branch solution worked without issue but the CERT branch (different local folder) gave the Security Debugging message when the ClickOnce Security settings were checked.
My solution: launch VS2019 as Admin. Problem is gone when debugging. And now I can launch without Admin and debugging is still good.
A quick solution with no explanation on why: Running my application in "Debug" configuration stopped the error and allowed my application to run.
When remote debugging my UWP application, VS always throws the following error after deployment process starts:
Error: Exception has been thrown by the target of an invocation.
Remote machine is a Win10 VM. The application runs fine when I select "Local Machine" from target machines list.
Things that I have ensured:
VM and development machine can see each other.
Remote tools are installed on the VM and Remote debugger is running.
Remote debugger says "[UserX] connected" when I start deployment, so VS is talking to it.
I have tried all 3 modes of authentication (None, Windows, Universal) and neither works.
I have restored NuGet packages, rebuilt all projects in the solution etc.
I have tried "Debug instead of Launch" checkbox and "Uninstall and reinstall my package" options too.
Has anyone else seen this behavior?
(Exception has been thrown by the target of an invocation generally contains a more specific exception inside it that shows what actually went wrong, but in this case I do not have any way to dig into the main exception).
Here's a snapshot of Output window:
Edit
Some more information. The error changes to the following if I choose Universal authentication:
Error: Field not found: 'Microsoft.VisualStudio.ImmersiveProjectServices.BootstrapperOperationPackage.StandardCollectorCpuAgent'.
Hi I'm developing a windows phone app and I use
System.Diagnostics.Debug.WriteLine()
function to write some debug info and when I run the program in debug mode while my phone is connected to my computer and visual studio there is no problem. but when I run the program without debugger - while installed in each of release and debug mode - those lines of debug info cause the app to encounter an exception!
can anybody explain what's going in there?
You can try to check if debugger is attached, then execute codes specific for debugging purpose only if IsAttached value is true :
if(System.Diagnostics.Debugger.IsAttached)
{
System.Diagnostics.Debug.WriteLine();
}
I created a Windows service in C# (4.0) and am trying to install it using installutil tool in command line. However I get an exception. I managed to find out what part of my code is causing the exception - using some crappy logging but whatever - but now I want to understand why. So what I want to do is debugging the installation of my Windows Service.
I know how to debug the service itself, but here, I want to debug the content of my Installer.Install(IDictionary stateSaver) method in the service.
I tried to attach the debugger to the cmd.exe process but it obviously doesn't work. I was thinking also to attach the debugger to the installutil process but I have no clue how to do this.
I had a look to this post: How do you debug a windows service that is being installed? and several others but in this case, for some reason, this guy seem to have his service already in the services.msc which is not my case.
How can I achieve this?
You can put a Debugger.Break(); statement in the installer code, and it should launch the debugger for you.
If the above does not work, I have found this process works too. Basically, you compile in debug mode and install the service (I used installutil.exe through the command line). In code you pop-up a message box with the process ID. Startup a second instance of studio, attach it to that process and debug. The message box pauses it to allow setup. The process ID isn't important, its named InstallUtil.exe. I usually put a Debug.Break() in after the message box to guarantee it enters the code.
using System.Windows.Forms;
using System.Diagnostics;
...
#if DEBUG
int processId = Process.GetCurrentProcess().Id;
string message = string.Format("Please attach the debugger (elevated on Vista or Win 7) to process [{0}].", processId);
MessageBox.Show(message, "Debug");
#endif
....
How to debug the installation of a custom windows service
I am creating a sandbox AppDomain so I can load up an assembly and release it.
var sandbox = AppDomain.CreateDomain("Sandbox", null,
AppDomain.CurrentDomain.SetupInformation);
However when I Load an assembly into to sandbox, the debugger crashes. I am in ASP.NET.
var assemblyName = AssemblyName.GetAssemblyName(assemblyPath);
var assembly = pluginDomain.Load(assemblyName); // crash here
Anyone know why this crashes?
Can you elaborate on what you mean by "Debugger Crashes". Does Visual Studio itself crash, does the debugger just stop and returns to Visual Studio design mode, does an exception dialog popup, etc ...
For all of these cases though the first thing I would do would be to change the following debugger options and repeat the scenario.
- Tools -> Options -> Debugger
- Uncheck: Enable implicit property evaluation
- Uncheck: Enable Just My Code
I had a similar issue: Only when debugging, my program quit without any exception when accessing AppDomain. After looking in the event viewer, I saw that Microsoft.IntelliTrace.Profiler caused application errors.
The solution was disabling intellitrace:
Uncheck: Tools -> Options -> intelliTrace -> Enable intelliTrace