René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Improve debuggability of the ConstrainedLanguage mode","articleBody":"### Summary of the new feature / enhancement\n\nToday, if PowerShell starts in ConstrainedLanguage, there's no way to tell **why** did this happen.\r\n\r\nThe problem is simply manifested as:\r\n\r\n```\r\nMicrosoft.PowerShell_profile.ps1: Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator.\r\n```\r\n\r\nThere're [multiple reasons](https://github.com/PowerShell/PowerShell/blob/319c93d6979fd99624c99b0a5ce49711378364bf/src/System.Management.Automation/security/wldpNativeMethods.cs#L186) for why the scripting is restricted and knowing which one exactly is very helpful when troubleshooting the issue.\n\n### Proposed technical implementation details (optional)\n\nThat'd be great if one could start pwsh in a mode where it would print out the high-level source of the issue (WLDP, AppLocker, cached or not, system or user, file policy enforcement).\r\n\r\nThe best would be if it could analyze CI policies present on the machine and highlight which one is the culprit (stretch goal.)","author":{"url":"https://github.com/wasker","@type":"Person","name":"wasker"},"datePublished":"2022-11-21T14:58:00.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/18628/PowerShell/issues/18628"}