none
'Access denied' auf Framework 4.0 'machine.config' mit Framework 3.5 Desktop Applikation RRS feed

  • Frage

  • Hallo,

    vielleicht könnt ihr mir weiterhelfen. Ich habe mich bereits im Netz totgesucht, und keine Hinweise gefunden.

    Ich habe unter Win XP / VS 2008 eine Desktop Anwendung für unsere Firma entwickelt. Lief bisher ohne Probleme.

    Jetzt werden unsere Computer auf Windows 7 umgestellt. Und da fangen die Probleme an: Wenn auf dem W7 Rechner das .NET Framework 4.0 installiert ist, dann verweigert die Applikation die Installation mit der Fehlermeldung:

    + Access to the path 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config' is denied

    Es funktioniert, wenn auf den W7 Rechner der Vollzugriff auf den o.g. Pfad eingerichtet wird. Na gut.

    Aber wieso will meine Framework 3.5 Anwendung plötzlich auf die Framework 4.0 'machine.config' schreiben ? Ich arbeite nirgendswo im Code mit der 'machine.config'. Und ich habe die Applikation extra so geschrieben, das sie für alles nur User-Rechte benötigt (Click-Once unter dem User-Account).

    Und bisher war auch nie Vollzugriff auf den Windows-Ordner erforderlich.

    Auf W7 Rechnern ohne Framework 4.0 funktioniert die Applikation ohne Probleme, und dort gibt es im System-Verzeichnis für 3.5 noch nicht mal eine 'machine.config' !?

    Weiss jemand was die Installationsroutine plötzlich mit Framework 4.0 und 'machine.config' zu tun hat, und ob es eine Möglichkeit gibt das zu unterbinden  ?

    Eigentlich möchte ich nicht auf hunderten Rechnern die Zugriffsberechtigungen anpassen lassen müssen. Das fände unsere IT Abteilung bestimmt nicht lustig ...  ;-)

    Vielen Dank

    Gruß

    Uli

     

    Donnerstag, 10. November 2011 11:19

Antworten

  • Hallo,

    noch mal als Update. Ich bin noch auf etwas aufmerksam geworden, in diesem Thread hier:

    http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/b121a1d2-6c5a-4c1b-b773-cb2bcc5aad64

    So wie ich hier und aus anderen Beiträgen herauslese ist ursächlich das Windows Update dafür bekannt speziell dem File 'machine.config' die Rechte zu kompromittieren. Tatsächlich ist es das einzigste File in allen 'C:\Windows\Microsoft.NET\Framework\vX.x\CONFIG\' Verzeichnissen, welches reduzierte Rechte aufweist. Auf einer frischen Installation hat es noch die User-Rechte, so wie alles andere auch.

    Mit meiner IT  Abteilung bin ich jetzt übereingekommen, das sie das als Windows-Bug einstufen, und dementsprechend die Ursprungsrechte für das File auf den betroffenen Rechnern wieder herstellen.

    Jetzt weiss ich zwar immer noch nicht warum mein Programm sich auf verschiedenen Rechnern auf verschiedene Framework-Versionen stürzt, aber ich muß auch nicht alles wissen ... ;o) Zumindest habe ich jetzt einen gangbaren Workaround gefunden.

    Vielen Dank

    Gruß

    u.

     

    • Als Antwort markiert ukabby Donnerstag, 19. Februar 2015 16:02
    Mittwoch, 16. November 2011 14:43

Alle Antworten

  • Hallo Uli

    ich finde auch wenig spezifisches, tendenziell aber (bzw auch daher) könnte es evtl  auf Probleme mit deiner IT-Infrastruktur (Fremd-SW, Passwörter) deuten, ähnliche:

    http://social.msdn.microsoft.com/forums/en-US/winformssetup/thread/85b1238e-8de5-4c77-afa0-71589d9ea5ca

    http://social.msdn.microsoft.com/Forums/en/netfxsetup/thread/b31432bc-5025-45a7-91aa-f96644ce4458

    Tipp: ggf mal mit einer frischen + puren Win7 Installation  (zB in einer VM) versuchen.

    P.S.
    Vielleicht solltest du hier den ganzen Fehler/Exception-Text posten.

    Freitag, 11. November 2011 19:27
  • Hallo, Thomas,

    Danke für die Antwort. Leider kann ich nicht viel selbst probieren, da ich nicht über IT Rechte verfüge. Aber es stimmt schon, das eine Problem ist die Firmen-Policy, die den Zugriff auf den Pfad auf dem eigenen Rechner verweigert. Da komme ich nicht drumherum die Rechte auf diesen Rechnern erhöhen zu lassen. Dann gehts ja auch.

    Aber die eigentliche Frage, die mich interessiert ist wieso eine Framework 3.5 Applikation auf die Framework 4.0 'machine.config' zugreifen muß, sobald das Framework 4.0 zusätzlich installiert wurde. Das ist eher jetzt eine Frage zum Verständnis des .NET Framework Verhaltens, damit ich zumindest weiss warum das so ist. Dann kann man ja irgendwie damit umgehen.

    Ich werde mir die Links mal vornehmen. Vielen Dank soweit !

    Gruß

    Uli

    P.S.: Hier noch mal die komplette Fehlermeldung:

    PLATFORM VERSION INFO
     Windows    : 6.1.7600.0 (Win32NT)
     Common Language Runtime  : 4.0.30319.239
     System.Deployment.dll   : 4.0.30319.1 (RTMRel.030319-0100)
     clr.dll    : 4.0.30319.239 (RTMGDR.030319-2300)
     dfdll.dll    : 4.0.30319.1 (RTMRel.030319-0100)
     dfshim.dll    : 4.0.31106.0 (Main.031106-0000)

    SOURCES
     Deployment url   : http://intra.company.com/intranet/DTS/zms-external/DTS/Install/DTS.application

    ERROR SUMMARY
     Below is a summary of the errors, details of these errors are listed later in the log.
     * Activation of http://intra.company.com/intranet/DTS/zms-external/DTS/Install/DTS.application resulted in exception. Following failure messages were detected:
      + Configuration system failed to initialize
      + An error occurred loading a configuration file: Access to the path 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config' is denied. (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config)
      + Access to the path 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config' is denied.

    COMPONENT STORE TRANSACTION FAILURE SUMMARY
     No transaction error was detected.

    WARNINGS
     There were no warnings during this operation.

    OPERATION PROGRESS STATUS
     * [11/10/2011 9:52:52 AM] : Activation of http://intra.company.com/intranet/DTS/zms-external/DTS/Install/DTS.application has started.

    ERROR DETAILS
     Following errors were detected during this operation.
     * [11/10/2011 9:52:55 AM] System.Configuration.ConfigurationErrorsException
      - Configuration system failed to initialize
      - Source: System.Configuration
      - Stack trace:
       at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
       at System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(String sectionName)
       at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
       at System.Configuration.ConfigurationManager.GetSection(String sectionName)
       at System.Configuration.PrivilegedConfigurationManager.GetSection(String sectionName)
       at System.Diagnostics.DiagnosticsConfiguration.GetConfigSection()
       at System.Diagnostics.DiagnosticsConfiguration.Initialize()
       at System.Diagnostics.DiagnosticsConfiguration.get_Sources()
       at System.Diagnostics.TraceSource.Initialize()
       at System.Net.Logging.InitializeLogging()
       at System.Net.Logging.get_On()
       at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
       at System.Net.WebRequest.Create(Uri requestUri)
       at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next)
       at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
       at System.Deployment.Application.FileDownloader.Download(SubscriptionState subState)
       at System.Deployment.Application.DownloadManager.DownloadManifestAsRawFile(Uri& sourceUri, String targetPath, IDownloadNotification notification, DownloadOptions options, ServerInformation& serverInformation)
       at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestDirectBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options, ServerInformation& serverInformation)
       at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options)
       at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
       at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
      --- Inner Exception ---
      System.Configuration.ConfigurationErrorsException
      - An error occurred loading a configuration file: Access to the path 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config' is denied. (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config)
      - Source: System.Configuration
      - Stack trace:
       at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
       at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
       at System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors()
       at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
      --- Inner Exception ---
      System.UnauthorizedAccessException
      - Access to the path 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config' is denied.
      - Source: mscorlib
      - Stack trace:
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
       at System.Configuration.Internal.InternalConfigHost.StaticOpenStreamForRead(String streamName)
       at System.Configuration.Internal.InternalConfigHost.System.Configuration.Internal.IInternalConfigHost.OpenStreamForRead(String streamName, Boolean assertPermissions)
       at System.Configuration.Internal.InternalConfigHost.System.Configuration.Internal.IInternalConfigHost.OpenStreamForRead(String streamName)
       at System.Configuration.ClientConfigurationHost.OpenStreamForRead(String streamName)
       at System.Configuration.BaseConfigurationRecord.InitConfigFromFile()

    COMPONENT STORE TRANSACTION DETAILS
     No transaction information is available.

    Montag, 14. November 2011 13:07
  • Hallo,

    noch mal als Update. Ich bin noch auf etwas aufmerksam geworden, in diesem Thread hier:

    http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/b121a1d2-6c5a-4c1b-b773-cb2bcc5aad64

    So wie ich hier und aus anderen Beiträgen herauslese ist ursächlich das Windows Update dafür bekannt speziell dem File 'machine.config' die Rechte zu kompromittieren. Tatsächlich ist es das einzigste File in allen 'C:\Windows\Microsoft.NET\Framework\vX.x\CONFIG\' Verzeichnissen, welches reduzierte Rechte aufweist. Auf einer frischen Installation hat es noch die User-Rechte, so wie alles andere auch.

    Mit meiner IT  Abteilung bin ich jetzt übereingekommen, das sie das als Windows-Bug einstufen, und dementsprechend die Ursprungsrechte für das File auf den betroffenen Rechnern wieder herstellen.

    Jetzt weiss ich zwar immer noch nicht warum mein Programm sich auf verschiedenen Rechnern auf verschiedene Framework-Versionen stürzt, aber ich muß auch nicht alles wissen ... ;o) Zumindest habe ich jetzt einen gangbaren Workaround gefunden.

    Vielen Dank

    Gruß

    u.

     

    • Als Antwort markiert ukabby Donnerstag, 19. Februar 2015 16:02
    Mittwoch, 16. November 2011 14:43