Log4Net.Async dll not copied to output if library is unreferenced in code

[rowandh]

If the Log4Net.Async library is only referenced in non-code (eg. a log4net log.config file), then the VS build process will not automatically copy the Log4Net.Async dll to the build folder for projects that reference other projects using Log4Net.Async. This occurs even if Copy Local is set to "True".

To get around this I created a dummy class whose sole purpose is to extend the RingBuffer class, without actually doing anything or being used anywhere at all.

A note about this in the documentation would be very helpful for those who are solely looking to wrap their existing appenders in their log config file.

[cjbhaines]

I have updated the readme with your solution, thanks for your feedback. I will leave this open until either myself or someone else comes up with an elegant solution. Perhaps even something as silly as a static method somewhere in the library to do a dummy initialize to actually reference the dll would be the best solution?

[johnnyreilly]

Hi @cjbhaines,

Was just trying out Log4Net.Async (which so far seems great - so thanks!) and I noticed this issue. For what it's worth I think there is a similar issue which I raised with the Entity Framework team here.

In the end the "official advice" became this:

You can add a line of code that references a type in the provider assembly. This line of code won't actually do anything and can be placed anywhere in your application var ensureDLLIsCopied = System.Data.Entity.SqlServer.SqlProviderServices.Instance;

So it doesn't sound like there is a particularly nice solution to this problem. But I thought you might like to know you're not alone :smile:

[rcollette]

I just created a new empty web project in VS2013, added log4net via nuget, referenced the log4net.async project and built and the log4net.async assembly was copied to the bin\debug folder of the web project.

[cjbhaines]

Richard, in that case I will close this off then, thanks for checking. Even if it didn't there's not really much we can do to address it, it's almost an issue with MSBuild outputs.

[vivek-meka]

Is there any code snippet/implementation on how to extend the RingBuffer class ?

[cjbhaines]

@PoorDesigner why would you want to extend it?

[vivek-meka]

I am using a shared library and Log4net async is only referred in config. I am trying to use the workaround that you mentioned

"To get around this I created a dummy class whose sole purpose is to extend the RingBuffer class, without actually doing anything or being used anywhere at all."

[vivek-meka]

I think I understood what we need to do. We need to refer the async library in the code somewhere so that the dll will be copied to output. I'll try that. Thanks

[cjbhaines]

@PoorDesigner so I did, my apologies it's been a while since I looked at this stuff. There was an open issue this afternoon with a suggestion to add an Attribute that could be applied in an AssemblyInfo to force the compiler to reference the library. I pushed a new NuGet package this afternoon and I've just updated the Readme in the Notes section with how to use this.

[vivek-meka]

when i try to use this in AssemblyInfo it gives me "Assembly generation failed as log4net.async doesn't have a strong name"

[cjbhaines]

That's a different issue. I do not sign the Log4Net.Async assemblies so if you are signing your assemblies you won't be able to reference it without a work around.

http://stackoverflow.com/questions/331520/how-to-fix-referenced-assembly-does-not-have-a-strong-name-error

[vivek-meka]

Yeah i looked through those. But i would like to know whether there is any chance of having a signed version for this one ? :)