YAHOOOO!

Thanks to all so kind to nudge me to the right solution. It was a security 
issue after all NOT a architecture problem. I tried to load the dll on the 
network by [void][Reflection.Assembly]::LoadFile($log4netDllPathString) .  I 
did not try to re-configure PowerShell execution by global config file. But I 
did change the load call to [void][Reflection.Assembly]:: 
UnsafeLoadFrom($log4netDllPathString)

Liebe Grüsse/Cordialement/Cordialità

Thiemo Kellner

--
Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse
IT-AB
Tel     +41 32 71 36516

Von: thiemo.kell...@bfs.admin.ch [mailto:thiemo.kell...@bfs.admin.ch]
Gesendet: Freitag, 27. Februar 2015 14:45
An: log4net-user@logging.apache.org
Betreff: AW: 64bit problem?

Thanks for the hint. I also found this configuration at 
http://stackoverflow.com/questions/19957161/add-type-load-assembly-from-network-unc-share-error-0x80131515

However, I would prefer not to change the PowerShell behavior in general. I'd 
rather to tweak a runtime setup. I am still investigation on that. I will let 
you know the outcome.

Liebe Grüsse/Cordialement/Cordialità

Thiemo Kellner

--
Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse
IT-AB
Tel     +41 32 71 36516

Von: Anthony Francisco [mailto:a...@recombulator.net]
Gesendet: Freitag, 27. Februar 2015 14:40
An: 'Log4NET User'
Betreff: RE: 64bit problem?

Older versions of .NET made it hard to load assemblies from the network. It's 
much easier with .NET 4 and up by using the <loadFromRemoveSources> 
configuration element.

See https://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx
See also: 
http://weblog.west-wind.com/posts/2011/Mar/22/Loading-Assemblies-off-Network-Drives

So what this means is that you'll need to update your powershell configuration 
file. It sounds like you might not have privileges to do that considering that 
you don't have privileges to put log4net and other assemblies on the local 
machine.


-          Ants

From: Dominik Psenner [mailto:dpsen...@gmail.com]
Sent: Friday, 27 February, 2015 03:48
To: 'Log4NET User'
Subject: AW: 64bit problem?

It might be a security issue then.

For instance, loading a dll from a network share is (from the operating systems 
point of view) a dangerous operation. When I try to open a zip file on my 
computer which is located on a NAS that "lives" outside of the network domain 
windows requires me to confirm 3 times a error message dialog at me stating 
"Windows cannot open the folder. The compressed zipped folder is invalid.", but 
then it opens up just fine.

Yes, windows is like that..

Von: thiemo.kell...@bfs.admin.ch<mailto:thiemo.kell...@bfs.admin.ch> 
[mailto:thiemo.kell...@bfs.admin.ch]
Gesendet: Freitag, 27. Februar 2015 08:42
An: log4net-user@logging.apache.org<mailto:log4net-user@logging.apache.org>
Betreff: AW: 64bit problem?

I am affraid, the dll file is there. Following code snipped should make sure it 
is before trying to load the dll

      if (-not (Test-Path -Path $log4netDllPathString)) {
            assert-fatal(
                  'I cannot find the logging library at "' +
                  $log4netDllPathString + '"')
            exit 1
      }
#       
[void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')
      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

and I actually can see the file with

C:\Users\s00489>dir 
I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll
Volume in drive I is WA-REF$
Volume Serial Number is 2702-33EF

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

18.11.2013  04:51           301'056 log4net.dll
               1 File(s)        301'056 bytes
               0 Dir(s)  137'992'851'456 bytes free

I cannot put the library elsewhere.

Maybe there is an issue because it is a network drive but I would not know why 
it would work on my own laptop then.
Liebe Grüsse/Cordialement/Cordialità

Thiemo Kellner

--
Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse
IT-AB
Tel     +41 32 71 36516

Von: Radovan Raszka [mailto:ras...@hasam.cz]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

It looks like powershell can't find where log4net.dll is located. As log4net is 
platform neutral (compiled as any CPU), I don't think 32 x 64 bit OS is issue.
Where you have log4net.dll installed? Probably is good idea to put it into GAC.
Or put it into folder where powershell is installed. Key is to find where 
powershell tried to find log4net.dll - is it possible to discover this info?
Radovan

From: thiemo.kell...@bfs.admin.ch<mailto:thiemo.kell...@bfs.admin.ch> 
[mailto:thiemo.kell...@bfs.admin.ch]
Sent: Thursday, February 26, 2015 4:19 PM
To: log4net-user@logging.apache.org<mailto:log4net-user@logging.apache.org>
Subject: AW: 64bit problem?

Assuming that on either system the most resent framework gets loaded, on both 
systems 4.0.30319 is used. However, on the server there are both flavours, 32 
and 64 bit. I do not know which one is loaded.

I forgot to mention that we use log4net 1.2.13, in case this makes a 
difference. The powershell version on the server is 3, on the laptop it is 4.

Liebe Grüsse/Cordialement/Cordialità

Thiemo Kellner

--
Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse
IT-AB
Tel     +41 32 71 36516

Von: Dominik Psenner [mailto:dpsen...@gmail.com]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

To be honest, the error message is rather cryptic to me. What I know is that 
log4net is not compiled against a specific architecture. If the targeted .NET 
framework is installed it should work. Have you checked that?

Von: thiemo.kell...@bfs.admin.ch<mailto:thiemo.kell...@bfs.admin.ch> 
[mailto:thiemo.kell...@bfs.admin.ch]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: log4net-user@logging.apache.org<mailto:log4net-user@logging.apache.org>
Betreff: AW: 64bit problem?

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a 
problem?

Liebe Grüsse/Cordialement/Cordialità

Thiemo Kellner

--
Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse
IT-AB
Tel     +41 32 71 36516

Von: thiemo.kell...@bfs.admin.ch<mailto:thiemo.kell...@bfs.admin.ch> 
[mailto:thiemo.kell...@bfs.admin.ch]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: log4net-user@logging.apache.org<mailto:log4net-user@logging.apache.org>
Betreff: 64bit problem?

Hi all

I am at my wits' end. We developped PowerShell script which uses log4net. I can 
run the script successfully from a batch file on my laptop but on the server I 
get

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'
provider failed.
I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :
Exception calling "LoadFile" with "1" argument(s): "The parameter is
incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"
At line:1 char:1
+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1
-stat_activi ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep
   tion
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio
   n,metadata_join_params-thiemo.ps1


I found 
http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll
 which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. 
As my laptop is 32 and the server 64 bit, I was wondering if this might cause 
the problem. At least I could pin the line of code where the exception gets 
thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

Has anyone an idea?

Liebe Grüsse/Cordialement/Cordialità

Thiemo Kellner

--
Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse
IT-AB
Tel     +41 32 71 36516

Reply via email to