I can confirm that this issue is due to the 7.3 upgrade. Worked fine in 7.2.6.

FYI http://issues.umbraco.org/issue/U4-6865

Hi Richard,

I encounter the same problem. Have you found a fix for this? As far as I can see at the moment, it can only be fixed by a core change and custom source compile.

Regards, Jasper.

Hope someone comes up with a solution for this. I'll keep tinkering with it, see if I can come up with a solution.

I tried updating the Umbraco dependencies (to 7.3.1) in the Umbraco-Console-Example but when I try to perform the 'list' command, I'm getting the original error:

ERROR: An unhandled exception of type 'Umbraco.Core.IO.FileSecurityException' occurred in Umbraco.Core.dll File 'Home.cshtml' is outside this filesystem's root.

var rootContent = contentService.GetRootContent(); // ERROR HERE ***

Full method:

private static void ListContentNodes(IContentService contentService)
    {
        //Get the Root Content
        var rootContent = contentService.GetRootContent(); <== ERROR HERE **********
        foreach (var content in rootContent)
        {
            Console.WriteLine("Root Content: " + content.Name + ", Id: " + content.Id);
            //Get Descendants of the current content and write it to the console ordered by level
            var descendants = contentService.GetDescendants(content);
            foreach (var descendant in descendants.OrderBy(x => x.Level))
            {
                Console.WriteLine("Name: " + descendant.Name + ", Id: " + descendant.Id + " - Parent Id: " + descendant.ParentId);
            }
        }
    }

Anyone know of a fix for this?

It appears the issue is with: GetRootContent()

If I run:

Umbraco.Core.Models.IContent content = contentService.GetById(1000);

... It works fine.

Its something with GetRootContent() which seems looks for the template on the filesystem as well. Not sure why.

I'm having the same problem after upgrading to version from 7.2.8 to 7.3.

The exception I am getting is:

File 'UmbracoPage.cshtml' is outside this filesystem's root.

This is obviously a problem with using the (until now) excellent UmbConsole example:

https://github.com/sitereactor/umbraco-console-example/tree/master/UmbConsole

Does anyone have a vague clue to where the error is coming from?

I've tried to be clever and create an 'UmbracoPage.cshtml' file at the root... but no joy.

Hi,

does anyone have a solution for this problem?

I also have the same issue. contentService.GetById(1000); is working when running from Visual Studio, but gives error of file outside this filesystem's root when running the executable outside Visual Studio

I'm also using the UmbConsole example app.

While trying to import a bunch of content items, I also ran into this issue with 7.4.0-beta2.

After having tried the solutions outlined in http://issues.umbraco.org/issue/U4-6865, which did not work for me, I simply changed the following in UmbConsole's ConsoleApplicationBase.cs, line 18:

var binDirectory = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory);

Set this to a root directory of a valid Umbraco website:

var binDirectory = new DirectoryInfo("D:\\Development\\MyUmbracoWebsite");

After making the change, I was able to fetch and create content.

This is happening to me since moving to 7.3.7.

Changing the bin directory just creates a load of new missing dll issues.

https://github.com/sitereactor/umbraco-console-example/tree/master/UmbConsole

is now broken and im sat here wondering how the hell im going to migrate my content in a sensible controlled (me) way and without paying for it.

So did anyone manage to get this workin on umb > 7.3 ? Facing the same issue...

Any solution behind this? I've tried to get some sort of physical context up, but there seems to be an unending dependency chain for the custom repository factory.

We are using 7.3.1 in a console app that grabs the umbraco data, but it seems like the system now checks for the views, which, don't exist. I was wondering if anyone else has found something that works as a get around without building the part of the source code of umbraco that it is requesting. the "Umbraco.Core.IO.PhysicalFileSystem.FIleExists" check.

The only methods that we are trying right now are either mocking the content before hand(which could be really unnecessary), or intercepting the call and returning it true always.

we're not sure yet if we can have parts of the solution be different versions of umbraco at the same time. For example having this console umbraco data grab app be version 7.2.1 and the umbraco website be 7.3.1.

More testing.

ideas?

after awhile i found this worked as a solution both in dev and publish. I revisited Raimonds idea and found the oddest thing. removing the slash in the domain call made it so umbraco didn't complain anymore. :-) so, from this:

var binDirectory = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory);

to this:

string regularPath = AppDomain.CurrentDomain.BaseDirectory;
            string newPath = regularPath.Remove(regularPath.Length - 1);
            var binDirectory = new DirectoryInfo(newPath);

Steps which helped me to fire up console app with latest v7.4.2 build:

1. Removed / renamed App_Start folder for the time of usage my console app (in my case Ninject startups and other startup code which can't be fired without mocks).
2. Try & catch exceptions during custom providers mapping to UrlProviderResolver.Current (is not accessible during startup in console).
3. Hacked Umbraco.Core (thanks to @AnthonyDotNet) and performed custom build of used version (v7.4.2 in my case) with replaced line "throw new FileSecurityException("File '" + opath + "' is outside this filesystem's root.");" in Umbraco-CMS\src\Umbraco.Core\IO\PhysicalFileSystem.cs to "return fpath;".
4. Backed-up / moved DLLs causing errors. In my case: Our.Umbraco.PropertyEditorConverters.dll which caused some erorrs with virtual paths.

After those steps console app created context and is working fine now.

FYI There is also this version that runs if you place it in your site root https://github.com/lars-erik/umbraco-console-example

Hi all,

Sorry for necroing this 1 year old post

I've made the required changes on Umbraco 7.5.7 so it can work with Console applications.

I've made a fork and a fixed release branch for this particular problem.

The problem I found was that the _rootPath was malformed and caused the directory not to be found, even if you placed the cshtml mocked file in the right folder it would always blow up because of that.

I hope this helps you all.

https://github.com/Mindbus/Umbraco-CMS/tree/release-7.5.7-GetRootContentFix

I created a console app in a separate project using the getbootmanager fix:

// This is a workaround for FileSecurityException (refer https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/72095-filesecurityexception-file-outside-root-in-console-app)
        string regularPath = AppDomain.CurrentDomain.BaseDirectory;
        string newPath = regularPath.Remove(regularPath.Length - 1);
        var binDirectory = new DirectoryInfo(newPath);

But then was seeing the file security exception error when trying to point back to the web project's root folder..

I then tried tim's app in the web root directory but it is unable to resolve an azure file system provider.

Can anyone confirm that for v7 I should be running the exe from the web project's root folder or should it be in the bin with then the boot manager base path modified etc?

My problem was that the BaseDirectory the ResolveBasePath method returned was not the same the first time I ran and on subsequent runs. This is because GetBootManager copies over the config folder to the binDirectory and so on successive runs the BaseDirectory was the same as the binDirectory.

//Copy config files to AppDomain's base directory
if (binDirectory.FullName.Equals(BaseDirectory) == false &&
    appDomainConfigPath.Exists == false)
{
    appDomainConfigPath.Create();
    var baseConfigPath = new DirectoryInfo(Path.Combine(BaseDirectory, "config"));
    var sourceFiles = baseConfigPath.GetFiles("*.config", SearchOption.TopDirectoryOnly);
    foreach (var sourceFile in sourceFiles)
    {
        sourceFile.CopyTo(sourceFile.FullName.Replace(baseConfigPath.FullName, appDomainConfigPath.FullName), true);
    }
}

It looks like this might have been by design, but it didn't work for me so I simply changed

BaseDirectory = ResolveBasePath(binDirectory);

to

BaseDirectory = ResolveBasePath(binDirectory.Parent);

is working on a reply...