Repository navigation
Reading configuration settings fails with System.UriFormatException: 'Invalid URI: The hostname could not be parsed.' #56897
Description
Description
Observed while using the new Windows Forms designer to design a migrated app from net461 to net5.0.
This doesn't appear to be a problem while running an app, but it is a problem when the code is executed in the Windows Forms designers (which is now run out of proc).
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString)
at System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig)
at System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig)
at System.Configuration.Internal.ConfigurationManagerInternal.System.Configuration.Internal.IConfigurationManagerInternal.get_ExeProductName()
at System.Configuration.ApplicationSettingsBase.get_Initializer()
at System.Configuration.ApplicationSettingsBase.CreateSetting(PropertyInfo propertyInfo)
at System.Configuration.ApplicationSettingsBase.EnsureInitialized()
at System.Configuration.ApplicationSettingsBase.get_Properties()
at System.Configuration.SettingsBase.GetPropertyValueByName(String propertyName)
at System.Configuration.SettingsBase.get_Item(String propertyName)
at System.Configuration.ApplicationSettingsBase.GetPropertyValue(String propertyName)
at System.Configuration.ApplicationSettingsBase.get_Item(String propertyName)
at GitCommands.Properties.Settings.get_IsPortable() in D:\Development\gitextensions2\GitCommands\Properties\Settings.Designer.cs:line 31
When I debugged in, for some strange reason AppDomain.CurrentDomain.BaseDirectory was returning \\?\C:\Users\igveliko\AppData\Local\Temp\WinFormsCache\exm5a4ew.gwt\
However when try run the same code locally AppDomain.CurrentDomain.BaseDirectory returns path without leading \\?\:
In essence this, what I think, is happening:
string baseDirectory = @"\\?\C:\Users\igveliko\AppData\Local\Temp\WinFormsCache\exm5a4ew.gwt\";
string manifestModuleName = @"DesignToolsServer.dll";
string configBasePath = Path.Combine(baseDirectory, manifestModuleName);
Uri uri = new Uri(configBasePath);
Console.WriteLine(uri.LocalPath);
Repro steps
git clone -v --recurse-submodules --depth 1 --no-single-branch --progress "https://github.com/gitextensions/gitextensions.git" "<path>/gitextensions"dotnet restore- Open GitExtensions.sln in VS
- Ignore Wix warning, trust all repos
- Navigate to
AppSettings.IsPortable()and removeIsDesignModediff --git a/GitCommands/Settings/AppSettings.cs b/GitCommands/Settings/AppSettings.cs - public static bool IsPortable() => !IsDesignMode && Properties.Settings.Default.IsPortable; + public static bool IsPortable() => Properties.Settings.Default.IsPortable;
- Compile
- Open
FormAboutin designer
Configuration
- .NET 5.0.6
- .NET: 6.0.0-rc.1.21401.1
Regression?
¯\_(ツ)_/¯ I struggle to tell what is the cause of this strange behaviour
Activity
RussKie commentedon Aug 12, 2021
@JeremyKuhne @Shyam-Gupta whilst we're waiting for a proper fix, is there something that we're setting in the designer that's causing this?
krwq commentedon Aug 13, 2021
@RussKie perhaps this help has some answers or workarounds: #3095
RussKie commentedon Aug 16, 2021
@krwq thank you, but I don't see any workarounds in that thread.
RussKie commentedon Aug 18, 2021
Added repro steps to the 1st post.
Shyam-Gupta commentedon Aug 18, 2021
While launching server process, WinForms designer sets process path in long path format. This is because the server process is launched from a
ShadowCacheFolderunder temp directory and it can potentially run into max path issues. It seems this path is returned as is byAppDomain.CurrentDomain.BaseDirectory. On removing long path characters from process path, issue gets fixed.So I think
AppDomain.CurrentDomain.BaseDirectoryneeds to account for long path format. Requesting @JeremyKuhne for his thoughts./cc: @merriemcgaw
RussKie commentedon Aug 18, 2021
/cc: @jeffhandley @danmoseley - can this be fixed in .NET 6.0?
jeffhandley commentedon Aug 20, 2021
This is reasonable to target for RC2 given that it's a regression from .NET Framework and blocking a key scenario. We'll need to get the fix into
mainfirst though, and ideally validate the fix there before porting into therelease/6.0branch.The port PR template will need to cover the details of potential risks that this introduces.
krwq commentedon Aug 23, 2021
@Shyam-Gupta @RussKie I’ve just tried to repro the issue and I’m able to when I set ProcessStartInfo.FileName to anything starting with
\\?\- when I set separately WorkingDirectory to anything starting with \?\ and then FileName as just a file name that works for me because AppDomain.CurrentDomain.BaseDirectory doesn’t contain\\?\.However when I tried to setup the same thing with the actual long paths I'm not able to run either of them and getting different kinds of errors when starting another process, i.e.:
Setting just FileName with long path starting with
\\?\gives me:which means the process is not even executed which wouldn't solve the issue.
If I try to set WorkingDirectory with long path starting with
\\?\and FileName with just a file name I get:on top of that trying to run any dotnet exe (hello world app) which is on a long path from a command line ends up with:
I'm not sure fixing just this issue will help in the long path issue case anyway so I'd suggest just not prepend
\\?\for now. I'm guessing there will need to be more fixes done to get this fixed for long path.I've also tried the same on latest 6.0 and the output was same.
JeremyKuhne commentedon Aug 25, 2021
@krwq This stuff should work. Feel free to ping me on teams regarding long path technical details. :)
RussKie commentedon Aug 25, 2021
We've had a chat with @JeremyKuhne, and it won't be correct move to modify the designer start up sequence. The BCL and the .NET runtime must handle long paths correctly, and in general they are.
Uriappears to be an outlier here.Here's a document outlining how to enable long paths https://docs.microsoft.com/windows/win32/fileio/maximum-file-path-limitation which you find helpful.
krwq commentedon Aug 25, 2021
I'll sync with @JeremyKuhne - my registry already shows that long paths are enabled and I added manifest file with longPathAware=true (I wasn't aware I needed it before) and I'm still getting "The current directory is invalid." when I try to run from the command line - although this looks like it comes from cmd.exe and not my .exe itself
krwq commentedon Sep 1, 2021
After syncing with @JeremyKuhne I believe I was correctly using manifest file and correctly enabled everything. I was able to run the app in cmd.exe from outside of the current directory (so that current directory is relatively short) and then using full path. For System.Diagnostics.Process I don't think it works with long paths, see the issue I've created - I've added potential workaround for long paths as well but it will only work if you don't pass any arguments to the exe:
#58492
If you use the workaround then after fixing this issue this scenario can be unblocked (assuming you don't pass any arguments to the app, if you do then last bullet point in #58492 has to be fixed as well)
RussKie commentedon Sep 20, 2021
@krwq I've used the private binaries and followed the steps you have kindly provided, but either I'm doing something wrong, or the issue isn't quite fixed.
Here's the stack trace I'm now getting (note it is not failing in
System.Configuration.ClientConfigPaths.GetTypeAndHashSuffix(String exePath, Boolean isSingleFile)):Here's a repro app (a butchered version of the real app that's exhibiting the issue): 56897.zip
Repro steps:
krwq commentedon Sep 20, 2021
@RussKie let's sync offline - the attached zip doesn't build for me