This, however, seems to always result in an exception being thrown, which says this:
The process cannot access the file 'D:\\Dev\\wegwijs\\UmbracoFramework\\data\\umbraco.config' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.Delete(String path)
at umbraco.content.ClearDiskCache() in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 656
at umbraco.content.SaveContentToDisk(XmlDocument xmlDoc) in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 857
at umbraco.content.<>c__DisplayClass10.<SaveContentToDiskAsync>b__f(Object ) in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 880
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
Of course, the first thing I checked (and reset) was the permissions on the umbraco.config file. This didn't help though.
Umbraco will happily let me publish these same pages from the backend (I select the parent and choose to publish that page and all its children, no problem).
The exceptions are thrown at random times in the loop, it's not one single node that causes the problem.
I also tried document.PublishWithSubs to mimick the way that Umbraco publishes the nodes from the backend, but then the umbraco.config does not get updated, so I'd still need to call UpdateDocumentCache.
It's not a permissions problem
It's got nothing to do with load balancing in the umbracoSettings, the distributedCall option is not enabled
There is nothing else accessing the umbraco.config that I know of (I have disabled scheduled tasks just to make sure)
Similar import scripts have never shown this behavior
Forgot to mention that this is Umbraco 4.0.4.1 and the code that it crashes on is in umbraco\presentation\content.cs (File.Delete causes the exception):
/// <summary>
/// Invalidates the disk content cache file. Effectively just deletes it.
/// </summary>
private void ClearDiskCache()
{
lock (_readerWriterSyncLock)
{
if (File.Exists(UmbracoXmlDiskCacheFileName))
{
// Reset file attributes, to make sure we can delete file
File.SetAttributes(UmbracoXmlDiskCacheFileName, FileAttributes.Normal);
File.Delete(UmbracoXmlDiskCacheFileName);
}
}
}
Well, I solved my own problem. My dev machine is apparently almost dead. My code works just great on my laptop. The dev machine felt really weird lately anyway, so it's for the best, time for a re-install!
UpdateDocumentCache throwing exceptions
I'm trying to create about 70-80 nodes through the API, they are created just fine and I need them to be published immediately after creation.
So, in my create loop, for each node I do:
This, however, seems to always result in an exception being thrown, which says this:
Of course, the first thing I checked (and reset) was the permissions on the umbraco.config file. This didn't help though.
Umbraco will happily let me publish these same pages from the backend (I select the parent and choose to publish that page and all its children, no problem).
The exceptions are thrown at random times in the loop, it's not one single node that causes the problem.
I also tried document.PublishWithSubs to mimick the way that Umbraco publishes the nodes from the backend, but then the umbraco.config does not get updated, so I'd still need to call UpdateDocumentCache.
Forgot to mention that this is Umbraco 4.0.4.1 and the code that it crashes on is in umbraco\presentation\content.cs (File.Delete causes the exception):
Well, I solved my own problem. My dev machine is apparently almost dead. My code works just great on my laptop. The dev machine felt really weird lately anyway, so it's for the best, time for a re-install!
is working on a reply...