RELOAD!

[rubberduck-vba/Rubberduck] 1 opened issue. 1 issue comment.

[Minesweeper] Games Played: 95, Bombs Used: 74, Moves Performed: 14136, New Users: 2

@MathieuGuindon rubberduckvba.com/Features/Details/CodeExplorer makes no mention of exporting a project. That's a great feature of CE when paired with git which enables proper version control.

@IvenBach damn that's right! ugh I should have had the admin site up months ago..

also my hyper-v being dead hasn't helped lol

I’m forming my lumpy RD + VC article and saw it wasn’t stated on the features page.

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.InternalApi/Common/FileSystemProvider.cs of pull request #5591: Move all usages of System.IO into System.IO.Abstractions or limit the using

so I just had this unit test fail:

// TODO: Remove this once this feature is stable and it can default to enabled.
[Category("Settings")]
[Test]
public void AutoCompleteDisabledByDefault()
{
    var defaultSettings = new DefaultSettings<AutoCompleteSettings, Rubberduck.Properties.Settings>().Default;
    Assert.IsFalse(defaultSettings.IsEnabled);
}

I'm fuzzy - is this on by default now?

  <setting name="AutoCompleteSettings" serializeAs="Xml">
    <value>
      <AutoCompleteSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" IsEnabled="true">
        <SmartConcat IsEnabled="true">
          <ConcatVbNewLineModifier>None</ConcatVbNewLineModifier>
          <ConcatMaxLines>25</ConcatMaxLines>
        </SmartConcat>
        <SelfClosingPairs IsEnabled="true" />
        <BlockCompletion IsEnabled="true" CompleteOnEnter="true" CompleteOnTab="true" />

looks like it's coming in as enabled. Why would not unit test fail until now? My changes have not touched either the app.config or the settings.settings.

Indeed, this was changed by a previous PR. So that unit test may not have worked... ?

Aren't default settings fun!

i'm still flummoxed as to what I could have done to cause the unit test fail. :-\

my working theory is that somehow I caused the app.config? or settings.settings? or ??? to be recompiled with the actual requested default and now it's failing. Not sure if that makes sense.

I remember there was some people reporting on github that app.config or settings.settings didn't match

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #5591: Move all usages of System.IO into System.IO.Abstractions or limit the using

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.InternalApi/Common/FileSystemProvider.cs of pull request #5591: Move all usages of System.IO into System.IO.Abstractions or limit the using

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.Parsing/ComReflection/XmlComProjectSerializer.cs of pull request #5591: Move all usages of System.IO into System.IO.Abstractions or limit the using

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.VBEEditor/Utility/FileExistenceChecker.cs of pull request #5591: Move all usages of System.IO into System.IO.Abstractions or limit the using

[rubberduck-vba/Rubberduck] build for commit 2fb1eaaf on unknown branch: AppVeyor build succeeded

@Duga I do not see which advantage a static instance of IFileSystem has over simply using the filesystem as represented by System.IO. The argument for injecting a filesystem in the first place was to allow injecting a fake filesystem in tests. So, I do not see why it is an argument for a static filesystem instance that there will only be one filesystem in production.

@M.Doerner as discussed in the issue #4533, the end goal is that all IO work should be unified. I envision extending IFileSystem to provide something akin to a chroot jail so that for RD's background work with VBComponent during import/export, there is a single class responsible for providing the paths and locating the files before/after. I figured it could implement the IFileSystem or something like that.