Change in working directory

[markolbert]

I’m migrating my Windows development from WPF to the Windows App SDK (WinUI 3). I’ve noticed the working directory has changed and now always appears to be c:/windows/system32, as defined in Environment.CurrentDirectory when called inside app code.

I’m curious as to why the change was made.

[castorix]

It works fine for me :

[nono3551]

For me both directories are set to system32.

So I started to set directory with:

var currentDirectory = Path.GetDirectoryName(Assembly.GetEntryAssembly()?.Location);
if (currentDirectory != null)
{
     Directory.SetCurrentDirectory(currentDirectory);
}

[BenJKuhn]

Are you running the app with administrative privileges or as built-in administrator by chance? I'm not an expert in this area, but suspect that might be a factor.

• Ben

[markolbert]

Oops, thanx for reminding me about this, @BenJKuhn! I should've answered/closed it earlier.

Turns out the problem was my misunderstanding how the Windows App environment has changed in some subtle but radical ways from WPF, WinForms, Windows console apps, etc.

As I've now learned, by design Windows Apps are installed to c:/Program Files/WindowsApps (which is a hidden folder to boot). Along with that, their "working directory" is c:/system/windows32...which cannot be written to by default.

What you have to do instead is utilize the application local folder (maybe roaming is available, too, I'm not in front of my development machine right now to check) to store things like log files, configuration files, etc.

Frankly, the documentation in this area is pretty weak. The information is there, but you have to know to look for it to find it. That's probably not a github problem, though. It's more a shortcoming of the Microsoft documentation.

[BenJKuhn]

Glad you found your answer even though I was a bit off the mark. I'd forgotten that as well. 😓

I'd welcome a suggestion as to where to leave some breadcrumbs on this behavior difference.

If changing code to address the difference is challenging, there's also the Package Support Framework (https://docs.microsoft.com/en-us/windows/msix/psf/package-support-framework-overview) which can patch-up certain differences in behavior like this to make porting code easier.

Ben

[markolbert]

I think I left a suggestion somewhere on the Microsoft documentation site about providing the information I'm describing. But I'm not sure, and I don't have a specific recollection about where that was.

I sorta see this as belonging on a page entitled "Fundamental Differences Between Windows Apps and WPF, WinForms, etc.". The problem is, what's a fundamental difference depends very much on the app you're writing, and on whether you've done any UWP programming (I never did) because I believe UWP contains the same frame shift.

[roxk]

Is this piece of doc helpful? https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes

The deployment doc has a link to What is MSIX (which itself isn't very helpful for migration) already. There is also a table laying out dis/advantanges of each model. Maybe it's worth adding a dedicated table with column such as "Install location", "Recommended files storage", "Register access", etc?

[markolbert]

That doc is/was very helpful, @roxk...when I finally stumbled across it :).

The problem is, when you don't know what to look for it's hard to determine where you should look for an answer. That's a general problem with all kinds of documentation, and it's why decades ago, when I spent a lot of time repairing my car because I was a broke teenager, I coined the phrase "No instruction manual, no matter how well written, ever contains more than 70% of what you need to know."

Interestingly, that observation could be/should be far less appropriate in the online world. The reason it applied/applies to printed manuals is that the cost of supplying additional context -- the missing 30% -- can be enormous. Because what you need to provide depends on the reader's level of understanding (i.e., the amount of context shared between a reader and the author). That's very idiosyncratic.

But in the online world it's at least theoretically "solvable" because the cost of displaying additional context/material is close to zero. You still have to pay to generate the content, but that can be amortized over a lot of users. More importantly, it can be community-driven (e.g., through a wiki). You're then only left with providing a filtering mechanism so that readers who don't need the additional context don't get drowned in it. But that's easy to do (e.g., via a dropdown allowing selection of expertise level).

On a practical level, referencing that behind the scenes piece in the "writing your first WinUI app" would help if it's not already there.

On a less practical, but still reasonable level, Microsoft ought to consider open-sourcing their developer documentation, along the lines of Wikipedia.

Okay, soap box disabled :).

[BenJKuhn]

Since you mentioned it, check out https://docs.microsoft.com/en-us/contribute/

I also gave feedback that particularly with respect to working directory, that article buries the lead. Some changes in titles, terminology and keywords would go a long way in helping with discoverability.

Ben

[grork]

I'm still a little unclear if the best practice here is for most app developers to change their working directory on app start? I 100% agree that apps should not write, or have permissions to write, to their install folder. But there are read scenarios where I feel this change a little lost.

I ran into this issue because a library I'm using includes some datafiles that it reads from during initialization (Yes, they could include it in the binary, but thats not applicable in all scenarios).

Because the working directory is %windir%\System32, a File.ReadAllLines("relative\\path.data") fails because it's not at C:\Windows\System32\relative\path.data.

What the background on making this change?

[DrusTheAxe]

You've touched on several issues so apologies for the length. And here we go...

1. runFullTrust capability docs
2. uap10:RuntimeBehavior and uap10:TrustLevel docs
3. RuntimeBehavior+TrustLevel vs EntryPoint
4. No <Capabilities> in package.appxmanifest
5. single project packaging type
6. Visual Studio / MSIX docs
7. Dependencies
8. win32App requires unvirtualizedResources

1. runFullTrust capability docs

First, and most obviously, this means that the description for this capability is wrong. There is a subset of desktop applications that don't need this capability.

Wrong indeed.

There's a set of packages that don't need this capability. Remember, an MSIX main package supports 0-100 <Application>s. No one said you have to declare any apps to have a valid package (albeit not the most common use).

"This capability is also required for any desktop application that is delivered as an appx or msix package

Terminology is a bear :-(

The phrase "desktop application" has been used to mean multiple things over the years, including RuntimeBehavior=win32app, packaged non-UWP apps (i.e. RB=win32app|packagedClassicApp) and apps that run on Windows' Desktop SKU, to name a few. In this sentence I think it's referring to RB=win32app.

The preceding paragraph is also inaccurate. The "Full Trust Permission Level" as in, runFullTrust capability, is defined as

The runFullTrust restricted capability allows apps to run at the full trust permission level on the user's machine.

This capability allows you to INSTALL packages containing 1+ FullTrust (aka MediumIL) thing. The capability has nothing to do with RUNNING anything, except in the most indirect sense (if you can't install you can't run...).

That link needs work. I'll follow up. Thanks for brining it to our attention.

2. uap10:RuntimeBehavior and uap10:TrustLevel docs

Secondly, there was a lot of information provided about how these packages work, but where is this documented? For example, where is uap10:RuntimeBehavior="packagedClassicApp" being combinable with uap10:TrustLevel="appContainer" documented?

uap10:RuntimeBehavior and uap10:TrustLevel are defined here but that page is thin on RB+TL and needs love.

Plus phrasing is inconsistent eg. ResourceGroup is "An option tag used to..." but uap10:Parameters is equally optional but phrased differently. Also, uap10:Parameters "Only supported for desktop apps that have package identity" is fine... if 'desktop app' was defined.

The obvious go to place, the manifest reference, doesn't even state that Windows.FullTrustApplication and Windows.PartialTrustApplication are valid values for the entry point.

So it doesn't. Huh. I haven't noticed that before. That's a bug, plain and simple.

The TrustLevel and RuntimeBehavior information does mention the appContainer, mediumIL, windowsApp, packagedClassicApp and win32App values, but there is no information as to what these even mean, let alone if there are any valid combinations with other attributes.

Fair point. The manifest docs are often more syntactical and leave deeper 'theory of operations' to other pages, but if so there should be links to them (as is done in various manifest doc pages).

There were some recent edits being made to the manifest docs but I doubt the doc writers have all this on their radar. I'll bring it to folks' attention. Thanks for raising the issues.

3. RuntimeBehavior+TrustLevel vs EntryPoint

But there are no indicators that if you specify uap10:TrustLevel="mediumIL", EntryPoint must be set to Windows.FullTrustApplication. Similarly, uap10:TrustLevel="appContainer" requires the value of EntryPoint to be set to Windows.PartialTrustApplication.

You can set either or both, but if you set both they must be consistent

1. EntryPoint="windows.fullTrustApplication"
2. uap10:RuntimeBehavior="packagedClassicApp" uap10:TrustLevel="mediumIL"
3. uap10:RuntimeBehavior="packagedClassicApp" uap10:TrustLevel="mediumIL" EntryPoint="windows.fullTrustApplication"

all produce identical results. The uap10 namespace was invented in 20H1 (aka Vibranium) so if your package installs on older systems you MUST specify EntryPoint="windows.fullTrustApplication" or Windows will see incomplete activation information and fail the install. If your package's <TargetDeviceFamily...MinVersion="10.0.19041.0"...> or higher then it only installs on versions supporting the uap10 namespace and you can skip EntryPoint and use the RB+TL properties.

The docs don't explain this equivalency. They should. Filing a bug...

4. No <Capabilities> in package.appxmanifest

As a fun side note, Visual Studio refuses to work without the runFullTrust restricted capability in the packaging projects.

I can't repro if I remove the runFullTrust capability. I can repro a problem if package.appxmanifest has no <Capabilities>. See below.

which corresponds to the Application element in the generated AppxManifest.xml file. Even if you try to manually set the EntryPoint attribute to "Windows.PartialTrustApplication", the tooling just sets it to full trust.

Where are you setting EntryPoint="windows.partialTrustApplication"?

If you create a new blank C++ WinUI app the project's package.appxmanifest has

  <Applications>
    <Application Id="App"
      Executable="$targetnametoken$.exe"
      EntryPoint="$targetentrypoint$">

which matches the project's Properties in VS (grrr, github won't paste the image)

If you change VS' Properties page from Entry point: $targetentrypoint$ to Entry point: windows.partialTrustApplication it builds. Right-click on the project in Solution Explorer and Package and Publish/Create App Packages... and walk thru the sideload option and it builds and runs as expected.

Remove the runFullTrust capability in package.appxmanifest and it's fine

<Package...>
  <!--
    THIS PACKAGE MANIFEST FILE IS GENERATED BY THE BUILD PROCESS.
  ...
  <Applications>
    <Application Id="App" Executable="BlankApp.exe" EntryPoint="windows.partialTrustApplication">
  ...
  <Capabilities/>

If you remove <Capabilities> element VS will error

Severity	Code	Description	Project	File	Line	Suppression State
Error	APPX0002	Task 'WinAppSdkGenerateAppxManifest' failed. Object reference not set to an instance of an object.
	BlankApp	C:\Users\howard\source\repos\BlankApp\packages\Microsoft.WindowsAppSDK.1.1.3\build\Microsoft.Build.Msix.Packaging.targets	901	
Error	MSB4018	The "WinAppSdkGenerateAppxManifest" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.
File name: 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
   at Microsoft.VisualStudio.Telemetry.MachinePropertyBag.ParseIn(String filepath)
   at Microsoft.VisualStudio.Telemetry.MachinePropertyBag.LoadStore()
   at Microsoft.VisualStudio.Telemetry.WindowsIdentityInformationProvider.<>c.<.cctor>b__12_0()
   at System.Lazy`1.CreateValue()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Lazy`1.get_Value()
   at Microsoft.VisualStudio.Telemetry.IdentityInformationProvider.SchedulePostPersistedSharedPropertyAndSendAnyFaults(TelemetrySession telemetrySession, ITelemetryScheduler scheduler)
   at Microsoft.VisualStudio.Telemetry.TelemetrySession.InitializeSession()
   at Microsoft.VisualStudio.Telemetry.TelemetrySession.HardwareIdCalculationCompleted(Object sender, EventArgs e)
   at Microsoft.VisualStudio.Telemetry.TelemetrySession.DisposeStart()
   at Microsoft.VisualStudio.Telemetry.TelemetrySession.DisposeManagedResources()
   at Microsoft.VisualStudio.Telemetry.TelemetryDisposableObject.Dispose()
   at Microsoft.Build.Msix.AppxPackagingTaskHelper.PostTelemetryFault(Exception e)
   at Microsoft.Build.Msix.AppxPackagingTaskHelper.Execute(String file)
   at Microsoft.Build.Msix.AppxManifest.WinAppSdkGenerateAppxManifest.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
	BlankApp	C:\Users\howard\source\repos\BlankApp\packages\Microsoft.WindowsAppSDK.1.1.3\build\Microsoft.Build.Msix.Packaging.targets	901	

That's a bug in (WinAppSDK's?) Microsoft.Build.Msix.Packaging.targets - it should handle no , fail if it's needed but OK if not. And regardless, never throw an exception. Filing a bug...

Workaround is to keep the element even if no child nodes e.g. <Capabilities/>.

5. single project packaging type

For a single project packaging type, it does properly use the "Windows.PartialTrustApplication" value, but the task just crashes if the runFullTrust restricted capability isn't declared.

Is the above exception what you're referring to by "task just crashes"?

6. Visual Studio / MSIX docs

Also, after checking through the MSIX documentation, the two Visual Studio pages referring to this (here and here) don't mention TrustLevel.

They don't mention RuntimeBehavior either. But they seem more quickstart than definitive (they don't mention lots of things you can do with MSIX) so that wouldn't be surprising.

The command line page referring to generating components (here) states that EntryPoint is always Windows.FullTrustApplication and that runFullTrust has to be added.
This kind of implies that Windows.PartialTrustApplication can't be used, and there is no mention of the TrustLevel and RuntimeBehavior attributes.

Indeed. That's either an over simplification or older guidance (or both). Will bring this to folks' attention. Thanks.

7. Dependencies

There is also the lack of other documentation about dependencies. Two examples of this are
TrustLevel being set to mediumIL requires the runFullTrust restricted capability.
RuntimeBehavior being set to win32App requires the unvirtualizedResources restricted capabilities.
Sure, they may be things that you run into once and then never forget, but still.

No objection there. Doesn't matter how often you touch it, docs are necessary.

8. win32App requires unvirtualizedResources

RuntimeBehavior being set to win32App requires the unvirtualizedResources restricted capabilities.

Apparently. I thought that wasn't the case but I was wrong. That's...interesting. Now I'm curious. Will ask around why that's so.

[DarranRowe]

Thank you for the reply. Thankfully, my reply isn't as long as yours. I have some final comments, but nothing paragraph inducing. I'll use your numbering here.

3. Not requiring the entry point requires the minimum version to be set to 2004/20H1 or higher? I never considered this case at the time, but it makes a lot of sense in hindsight. Thank you for mentioning this.
4. I did mention it in my follow up, but since it was so small compared to the rest of what I wrote then it is easy to miss. I was originally trying to set the entry point directly in Package.appxmanifest. I did eventually figure out that this was incorrect. I did find the proper way of setting the trust level for the packaging project in properties. I just didn't consider looking over at the properties window with the application selected. This was a case of expectations, and I expected that this kind of setting would be in the project properties accessible from Solution Explorer. This expectation caused me not to look in the properties window.
   Once I found this then things worked as expected.
5. Yes, the exception is what I meant by crash.

Anyway, thank you for spending the time looking into things and doing the work, especially since a significant amount of my frustration was perceivable from those posts.

[mlkauppila]

If it is a separate packaging project, it will always force the EntryPoint attribute for the Application element to Windows.FullTrustApplication.

Hello, I was running into the same problem. In the Windows Application Packaging Project, which packages my web application project, I have set the EntryPoint="windows.partialTrustApplication" attribute in the Package.appxmanifest, but that does not work and if I read you correctly that would be the incorrect place to set it, anyway. Is there a way to find out the reason just why the tooling overrides the EntryPoint attribute to Windows.FullTrustApplication?

I also tried to follow the steps of the solution you found, but couldn't find a way to set the trust level for my web application project directly from it's Properties window.

[DarranRowe]

Okay, the information that I am about to give was obtained by packaging a C++ Windows API desktop application. It shows the things that I needed to do in order to get the application packaging project problems fixed. I'm not sure if this will help you.

First of all, just creating the application packaging project and adding the desktop application as a reference, the project would show that there was a problem.

The partial trust option was also not available in properties.

I had also noticed that C++ WinUI 3 projects don't have this problem. Looking in the project (.wapproj) file itself, I found a really cheap and easy way to get the project to be partial trust. If you open the project up and find the line with the project reference, as an example:

  <ItemGroup>
    <ProjectReference Include="..\BasicTestWindow\BasicTestWindow.vcxproj" />
  </ItemGroup>

You can modify this to include the trust information:

  <ItemGroup>
    <ProjectReference Include="..\BasicTestWindow\BasicTestWindow.vcxproj">
      <TrustLevel>Partial</TrustLevel>
    </ProjectReference>
  </ItemGroup>

This won't clear the problem in solution explorer, but it will get the projects to make the packages with the windows.partialTrustApplication entry point. If you are targetting Windows 10 2004 (20H1/19041) or later, another option is to remove the entry point option. If you then add the uap10:RuntimeBehavior and uap10:TrustLevel attributes, and set them to "packagedClassicApp" and "appContainer" respectively, then you will get the same behaviour as the entry point being set to windows.partialTrustApplication. But as stated, this will only work if you are targetting at least Windows 10 2004 as the minimum version. The project system will also complain about the missing EntryPoint attribute. You can find more information about this in the application appx documentation.

However, I still saw these options as hacky workarounds. Therefore, I kept looking for the proper solution. Because I had noticed that WinUI 3 projects had no issues setting this setting, I went back to look at the differences. One thing that I did notice was that the WinUI 3 project had an additional Identity value:

This was pointing to the .winmd file that the project was generating. For C# applications, this points at the main executable. This would mean that what the project system is looking for is .NET metadata. So in this case, I added the C++/WinRT nuget package, added a .idl file to the project and had that contain a runtimeclass definition in the same namespace as my project. This resulted in the generation of a .winmd file that the packaging project would use.

Notice how there is now an Identity value there, and Full Trust is selectable? So the application packaging project needs to see metadata to make the trust option available. But as already discussed, the packaging itself doesn't need this, so you can manually set the trust value or even manually do all of this outside of Visual Studio and it will work.

[DrusTheAxe]

Awesome write up! Thanks for sharing.