I've configured a simple console app to work with log4net. I was able to successfully get log4net to write to a log file; however, it's throwing an exception when I try to write to the database. I get the following:
System.TypeLoadException: Could not load type
[log4net.Appender.AdoNetAppender]. Tried assembly [log4net,
Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44 e1d426115821]
and all loaded assemblies
I went first to the dll to check out the available appenders, and AdoNetAppender isn't there, so it would make sense that it couldn't be loaded. I thought this might be a problem with the dll I downloaded from Apache, so I went to SourceForge to get an older copy... and when I checked that dll, it didn't have AdoNetAppender either! I can't imagine this is that difficult. Am I missing something obvious?
I've got an issue with log4net and the AdoNetAppender whereby it'll only write to the DB if System.Data.dll is present in the bin directory along with the log4net DLL. It's worth trying this if you haven't already solved this problem.
Related
We have an application where we have several Azure WebJobs set up, and we have NLog set up to report on the entry and exit of those webjobs. We have NLog hooked into Stackify so that we can use the Stackify logger to watch things move from WebJob to WebJob. The logging works (so we know the configuration is OK). The problem we are hitting is that the logging is intermittent - we have independent confirmation of messages travelling along several WebJobs, but we will only get partial logging. For example, the first log will record that a message was read off of it, but won't show the exit message. The next log will show the entry and exit. The problem is that they all leverage the exact same code, so the same log message should appear every single time. Has anyone else encountered this issue before? Before you answer, we have taken these diagnostic steps:
(1) We have verified the proper configuration settings in all webjob config files.
(2) We have verified that all of the webjob config files are properly posted in Azure.
(3) We have independently verified (via the webjob consoles in Azure) that the messages are getting to the different webjobs, processing, and then moving on to the next webjob, meaning that they would be invoking the logging code.
(4) We have verified that our Stackify log data is not being throttled (this might have made sense if the logs had simply stopped - but the fact that we just get partial logging in some cases and full logging in others during a single message transmission makes this unlikely).
(5) We have pored over the Stackify documentation, which seems to ensure that configuration is set up properly so that you get logging at all. It covers the all-or-nothing scenario, but not the some scenario.
I will be happy to provide more clarification as needed.
We discovered what is going on, and it is rather strange. The issue ended up being with our use of NLog.Targets.Stackify. We were using version 1.25.4. When I ran a test using the NLog debugger suggested by Julian, this is what showed up:
2017-01-09 10:14:43.5079 Info Loading assembly name: NLog.Targets.Stackify
2017-01-09 10:14:43.5449 Debug ScanAssembly('NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c')
2017-01-09 10:14:43.5929 Debug Start auto loading, location: C:\Dev\AffinityMain\platform\Integrity.WebJob.Rating\bin\Debug
2017-01-09 10:14:43.5929 Info Auto loading assembly file: C:\Dev\AffinityMain\platform\Integrity.WebJob.Rating\bin\Debug\NLog.Targets.Stackify.dll
2017-01-09 10:14:43.6039 Info NLog.Targets.Stackify, Version=1.18.6200.39247, Culture=neutral, PublicKeyToken=null. File version: 1.18.*. Product version: 1.25.4.
2017-01-09 10:14:43.6039 Debug ScanAssembly('NLog.Targets.Stackify, Version=1.18.6200.39247, Culture=neutral, PublicKeyToken=null')
2017-01-09 10:14:43.6249 Warn Type load exception. Exception: System.IO.FileLoadException: Could not load file or assembly 'NLog, Version=5.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'NLog, Version=5.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c'
This was followed shortly by this error when it was parsing the config:
System.ArgumentException: Target cannot be found: 'StackifyTarget'
The documentation indicates that version 4.4 of NLog is sufficient to run this library. However, the NLog debugger indicates that it is looking for version 5.0, and not finding it (which it wouldn't because we aren't using it). Now, what makes this strange is that it did work at one time, with this version, so somehow a reference to NLog 5.0 is stuck somewhere in the system, but we can't find it because everything in our solution is running NLog 4.4. We've checked the csproj, the packages config, the app config, the actual installed nuget packages - no reference to version 5.0.
The answer to the problem was to downgrade to 1.25.3. As soon as I did that, it worked. I then tried to bump it back to 1.25.4, and had the same problem again. Matt - to your point about Shutdown - we are going to add that to our webjobs, and then I will monitor to see if we are seeing complete logs. Thank you everyone for your suggestions!
You should be able to fix this problem by adding one line of code at the end of your application to StackifyLib to flush.
StackifyLib.Logger.Shutdown();
https://github.com/stackify/stackify-api-dotnet/blob/master/README.md
I hope this fixes it for you, if not, please contact Stackify support.
Could be nice with an example of the NLog-config. If using the async-wrapper, then by default the overflow action is to discard "random" messages.
I'm getting a run time exception in my deployed, exported, and then imported to another box... CRM Solution. The Exception is:
System.TypeLoadException: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
It only occurs when I use a MSBUILD script to do this. When I use VS (2010) by hand to do this, all is well. So, first suspect is my script. My script uses a MSBUILD custom task, inspired by http://fczaja.blogspot.com/2012/07/continuous-integration-with-crm.html.
My sense is the issue could be on the Export step - which uses the Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy, up-cast to IOrganizationService.Execute, passing an ExportSolutionRequest object. We set the SolutionName and Managed properties only. Perhaps we're missing another property?
I'm trying to narrow it's root cause.
Are you by any chance using ILMerge on your plugin assembly?
If so I suspect it is an issue with your reference assemblies, perhaps having .NET 4.5 on the build server but not on the machine where you build it manually.
These links will explain futher if this is indeed the case:
http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx
The fundamental fix is to change your ILMerge reference assemblies to be -/targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
In order to get Portable Library Projects v2 working in MonoTouch, I'm currently jumping through a small number of hoops.
One of them is that I'm building a forwarding DLL for System.Net methods (see some explanation in http://slodge.blogspot.co.uk/2012/04/using-portable-library-tools-for.html)
However, I'm having some problems actually generating a DLL with the right name - because if I generate it as System.Net then I get an error during build of:
Error CS0281: Friend access was granted to System.Net,
PublicKeyToken=7cec85d7bea7798e', but the output assembly is named
System.Net, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
Try adding a reference to `System.Net,
PublicKeyToken=7cec85d7bea7798e' or change the output assembly name to
match it (CS0281) (System.Net.Touch)
I do have a way around this - generating the file under a different name and then manually renaming it afterwards. But I'd prefer to avoid this step if I can.
Can anyone suggest a way to avoid this error while still generating an assembly called System.Net?
Not sure if that helps. I was able to take your code and build a delay signed System.Net, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e in Visual Studio 2010. Then successfully used that DLL to build a simple application (One PCL + One MonoTouch) to compile and run in both VS/Windows and Xamarin/Mac.
After months of research on this, it seems that the only way to do this within a solution is the workaround I already had:
I do have a way around this - generating the file under a different name and then manually renaming it afterwards. But I'd prefer to avoid this step if I can.
Hopefully this won't be needed soon anyway - as we have official Xamarin PCL support under production right now.
In Microsoft Dynamics CRM 2011, I wrote one plug-in in C# for Account entity to do some operations on fields when Account record is created. In C# code I created my own custom assembly called My.Custom.Assembly.dll. Which contains some generic methods those I can use often in my plug-in. And I using this My.Custom.Assembly.dll and also added in reference in my project. Project builds successfully and plug-in registration also. The problem I faced when I was creating a Account record. Its throwing an error: "Could not load file or assembly My.Custom.Assembly.dll, Version=1.0.0.0 Culture=neutral, PublicKeyToken=def751c98b41d765 or one of its dependencies.The System cannot find the file specified." I got to know the problem is with My.Custom.Assembly.dll. Can you please help me to solve this problem..?
Your custom assembly cannot be loaded during the execution of your plugin.
Either install it in the GAC or merge it with your plugin assembly.
See my answer at Plugin with references not working on CRM 2011
A good place to start debugging this type of issue is to use Fusion Log Viewer to see the details of how .Net runtime is attempting to load the assembly. http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.100).aspx
Based on what you find in the log post more details if you need additional assitance.
You may also want to read up on How .net loads Assemblies
VSeWSS Deployement cast loader exception:
Do anyone have any ide of solution to this problem.
Error 1 VSeWSS Service Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Log file written to: C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log
2010.01.13 10:31:27 Error
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
I only work with GAC deploys, this is my experience with it:
LoadException means a sequence of:
CopyToLocal is set in an assembly reference, this assembly will be included in the WSP package.
VSeWSS tried to deploy, it retracted the solution (thus removed the reference assemblies from the GAC) but something went bad, but it never saved anywhere that the solution was retracted but an error occured.
You attempt a new deploy, the reflection code in VSeWSS attempts to load the CopyToLocal assemblies in the GAC, they dont exist. LoaderException is thrown.
if you open the GAC, you sometimes SEE the assembly there! IT'S A TRAP :) if you F5 the GAC the assembly will be properly gone.
In case this is what happens, the solution is:
Manually Add the CopyToLocal assemblies to the GAC
restart IIS (or recycle the VSeWSS pool)
profit
a 'Clean Solution' might also help between steps 2 and 3.