I am doing the T300 Acumatica YogiFon exercise online course. Publish is successful, but on attempting to save the Customer after making changes, I got the error below:
Message from webpage
[A]PX.Objects.CR.ContactExt cannot be cast to [B]PX.Objects.CR.ContactExt. Type A originates from 'RuntimeCode_1AEBD00CDE079136, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\Program Files\Acumatica ERP\Customization\AcumaticaERP\Temp\10f57cd610be4063b2c106062a7f3e47\RuntimeCode_1AEBD00CDE079136.dll'. Type B originates from 'RuntimeCode_1AEBD059B2E07F24, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\Program Files\Acumatica ERP\Customization\AcumaticaERP\Temp\10f57cd610be4063b2c106062a7f3e47\RuntimeCode_1AEBD059B2E07F24.dll'.
OK
I tried "publish with cleanup". But this worked sometimes. After changes here and there, and republishing, it fails again.
Update...
After I restart the whole machine, then it works.
The version I am running is --> 19.111.0038
Training is not up to date and in newer versions of Acumatica there's a conflict with multiple contact DAC extensions. I would advise to skip this part of training.
You can try renaming the DAC or having it in a different namespace but other vexing errors do occur. Not really worth fixing if your goal is just to go through training.
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 having an issue as below:
Could not load file or assembly 'msshrtmi, Version=2.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'msshrtmi, Version=2.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine why the assembly 'msshrtmi, Version=2.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' could not be loaded.
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
The issue happens only when publishing to Windows Azure Websites (WAWS). I want to detect whether I am running in Windows Azure mode or not. Is this possible in WAWS? This error is happening only when I call Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.IsAvailable.
I'd assume that the WAWS environment would have the Azure SDK installed, right? Or is this only available for Cloud services?
I've looked at some solutions telling you to manually include it in x64 or x86 version, but I would like not to be limited that way, or similar workarounds.
I encountered this same error when publishing a Web App. After trying every other solution on the web, the following finally worked for me:
In the Azure Portal, select your Web App. Select 'Settings > Application settings'. Change the Platform value from 32-bit to 64-bit. Re-publish.
After upgrading to ServiceStack v3.9.70 via nuGet from v3.9.43, I noticed that the ServiceStack.Interfaces.dll is no longer copied over to projects that depend on the class library using ServiceStack. This causes the following error:
System.IO.FileNotFoundException: Could not load file or assembly 'ServiceStack.Interfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'ServiceStack.Interfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
All other ServiceStack dlls are copied, only ServiceStack.Interfaces is missing. All references are set to Copy Local = True, and this StackOverflow post's suggestion does not solve the problem.
I noticed that ServiceStack.Interfaces.dll is the only one with a version of 1.0.0.0, all others are set to 3.9.70.0. Could this be a cause?
Does anyone know how to fix it without manually referencing ServiceStack.Interfaces.dll in cascade in all projects referencing my class library?
Update - 2014-03-06
Problem still exists with v3.9.71.0. It really is related to the fact that the ServiceStack.Interfaces assembly has its version left to 1.0.0.0 instead of being.
I cloned the github repository for ServiceStack and changed this line in the build\build.proj file and ran build\build.bat.
<!-- Exclude versioning future strong-named libs -->
<RegexTransform Include="$(BuildSolutionDir)/src/**/AssemblyInfo.cs"
Exclude="$(SrcDir)/ServiceStack.Interfaces*/Properties/AssemblyInfo.cs">
<Find>\d+\.\d+\.\d+\.\d+</Find>
<ReplaceWith>$(Version)</ReplaceWith>
</RegexTransform>
for this (noticed the removed exclusion)
<RegexTransform Include="$(BuildSolutionDir)/src/**/AssemblyInfo.cs">
<Find>\d+\.\d+\.\d+\.\d+</Find>
<ReplaceWith>$(Version)</ReplaceWith>
</RegexTransform>
Result: Now it works correctly, i.e. the file ServiceStack.Interfaces.dll is copied over to projects referencing a project that references ServiceStack.
Can someone explains this to me? Why would you want to exclude the Interfaces from versionning?
The assembly versions were intentionally changed from 3.9.* to 1.0.0.0 when the v4 was released.
It probably was due to v4 ServiceStack.Interfaces.dll being changed to being strong-named and versioned 4.0. The 'bsd' 3.9.* version was rolled back to 1.0, probably to be clearly the oldest possible.
More detail in noted in this SO answer.
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"
Late last week I upgraded CC.NET locally and on the build server. The build server is still fine, but locally I am now getting the following error:
Exception Details: Exortech.NetReflector.NetReflectorTypeLoadException: Unable to load types from assembly System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:
Failed to load 1 of the 3612 types defined in the assembly.
Exceptions:
- Unable to load type: System.Security.Authentication.ExtendedProtection.ChannelBinding
Exception: System.TypeLoadException: Could not load type 'System.Security.Authentication.ExtendedProtection.ChannelBinding' from assembly 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
I'm afraid this started after a batch of Windows updates this morning. I had another two updates that won't run, 979909 and 982168 (I had an update that wouldn't run last month).
Anyone else having any issues? Thanks!
Edit: I can connect through CCTray and CCNET is running properly. I just can't get to the Dashboard.
EDIT. Thanks to both of you. I uninstalled
everything you both suggested and
turned off Windows Update per our IT dept. It didn't
work yesterday after a reboot, but
after a night of rest and another
reboot, it seems to be working now.
I got the same exception this morning, seemingly out of nowhere.
Turns out some Windows updates were installed over the weekend. After uninstalling the KB976765 and KB979909 updates, the problem went away.
I hope this helps
There is a problem with the update KB976769v2. It can be fixed as detailed in this KB article.
We had the same problem. For us we had to uninstall KB976769v2 in order for the application to work again.