Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect assembly name in nuget package Castle.Core-log4net #324

Closed
beginor opened this issue Nov 28, 2017 · 3 comments
Closed

Incorrect assembly name in nuget package Castle.Core-log4net #324

beginor opened this issue Nov 28, 2017 · 3 comments
Labels
Milestone

Comments

@beginor
Copy link
Contributor

beginor commented Nov 28, 2017

When deploy to linux, I got the flowing error:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Castle.MicroKernel.SubSystems.Conversion.ConverterException: Could not convert string 'Castle.Services.Logging.Log4netIntegration.Log4netFactory,Castle.Services.Logging.Log4netIntegration,Version=4.0.0.0, Culture=neutral,PublicKeyToken=407dd0808d44fbdc' to a type. Assembly was not found. Make sure it was deployed and the name was not mistyped.
  at Castle.MicroKernel.SubSystems.Conversion.TypeNameConverter.GetType (System.String name) [0x000e7] in <da07e4a3dbff400986e1fa0da51c098b>:0 
  at Castle.MicroKernel.SubSystems.Conversion.TypeNameConverter.PerformConversion (System.String value, System.Type targetType) [0x0000b] in <da07e4a3dbff400986e1fa0da51c098b>:0 
  at Castle.MicroKernel.SubSystems.Conversion.DefaultConversionManager.PerformConversion (System.String value, System.Type targetType) [0x0001e] in <da07e4a3dbff400986e1fa0da51c098b>:0 
  at (wrapper remoting-invoke-with-check) Castle.MicroKernel.SubSystems.Conversion.DefaultConversionManager:PerformConversion (string,System.Type)
  at Castle.MicroKernel.SubSystems.Conversion.DefaultConversionManager.PerformConversion[TTarget] (System.String value) [0x00000] in <da07e4a3dbff400986e1fa0da51c098b>:0 
  at Castle.Facilities.Logging.LoggingFacility.GetLoggingFactoryType (Castle.Facilities.Logging.LoggerImplementation loggerApi) [0x00070] in <0c3db78b6aba4b999cd2ecc63cfb3b9e>:0 
  at Castle.Facilities.Logging.LoggingFacility.CreateProperLoggerFactory (Castle.Facilities.Logging.LoggerImplementation loggerApi) [0x00000] in <0c3db78b6aba4b999cd2ecc63cfb3b9e>:0 
  at Castle.Facilities.Logging.LoggingFacility.ReadConfigurationAndCreateLoggerFactory () [0x00007] in <0c3db78b6aba4b999cd2ecc63cfb3b9e>:0 
  at Castle.Facilities.Logging.LoggingFacility.Init () [0x0000e] in <0c3db78b6aba4b999cd2ecc63cfb3b9e>:0 

When I check the bin directory, The assembly I found is Castle.Services.Logging.log4netIntegration.dll, after I rename it to Castle.Services.Logging.Log4netIntegration.dll, it works!

This should be a spell mistake, but will break Castle.Core-log4net runing on case sensitive file system, please correct it!

@jonorossi
Copy link
Member

It appears this was broken in 4.0.0. Previously in 3.3.3 the binary was named Castle.Services.Logging.Log4netIntegration.dll.

This has happened with the change to the new .NET tooling because the project file didn't match the assembly name:

  • Castle.Services.Logging.log4netIntegration.csproj
  • Castle.Services.Logging.Log4netIntegration

@beginor could you provide a pull request fixing the assembly name?

Just a side note: there are deprecation changes to the logging facility in Windsor 4.1.0 that affect this code path.

@jonorossi jonorossi added the bug label Nov 30, 2017
@jonorossi jonorossi added this to the vNext milestone Nov 30, 2017
@beginor
Copy link
Contributor Author

beginor commented Dec 1, 2017

OK, maybe I can try it later

@jonorossi
Copy link
Member

Thanks for the fix, I've merged it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants