We have a customer that has an old version of some software installed.
There is a problem and we have a fix for it. Only we can't deploy it at the customer.
I'm not an AX guy myself, but I don't understand the problem either.
We have decompiled the "old" dll, made a small change, recompiled it again with the same version numbers etcetera and signed the dll with the same key.
If I open both versions with dotPeek I see they have the exact same assembly name.
Then when I replace the "old" dll with the "new" dll and run the AX code I get following errors:
"Assembly containing type 'namespace.type' is not referenced."
"Object 'CLRObject' could not be created."
"A critical error has occurred in function [nameOfAxFunction]."
So why does it not take the new dll?
Does AX do a check on the hash of each dll that it load and therefore block my new version?
Do we need to recompile the AX code ... ?
Also in the AX function it fails when creating a new instance of a type that is in our modified assembly. So it's not even that we access another dll that fails to load our new dll, we go directly from AX to the new version of the dll.
Ps:
I have double checked and the type is still in the assembly.
Assemblies replaced in:
"Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin" &
"Program Files\Microsoft Dynamics AX\60\Server\[env-name]\bin"
Related
I created a Send Pipeline that has a Flat File Assembler. When I tried to send the Message I am getting error like, Error Code 0xc0c01658 (Send Pipeline Error)
The detail of the error:
Please verify that the pipeline strong name is correct and that the pipeline assembly is in the GAC
Can anyone help me? I am new to BizTalk and I am learning
Check to see that the Pipeline is in the GAC (C:\Windows\Microsoft.NET\assembly\GAC_MSIL)
There should be a folder there with the Assembly name (Jax.Dhana.SamplePRJ), and then a sub folder which will be in the format of .NetVersion_DLLVersion_PublicKey e.g. v4.0_1.0.0.0_cf96c3b300e6dd40 and under that should be the DLL. If the Name, Assembly Version Number or Public Key do not match then it will not be able to find it in the GAC.
Try to remove the existing assembly in gac using gacutil -u and then reinstall the latest assembly.
Check if you have added the pipeline to BizTalk using add resource, or try doing it again anyway.
We recently did some code reorganization for our ASP.NET web site solution and I've run into an unfriendly issue with the TFS 2010 SDK assemblies that I haven't been able to figure out.
We have a small class (I included the functions using TFS SDK below) that retrieves all the TFS changeset comments since the last time we deployed the website. The web site project has the following references to use the TFS SDK:
Microsoft.TeamFoundation.Client
Microsoft.TeamFoundation.VersionControl.Client
The class used to live in the App_Code folder of the project and the following TFS assemblies were deployed in the bin folder of the site:
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
This worked properly with no errors when deployed to the site.
We moved this class (along with several others) into a separate class library and removed it from the App_Code folder of the site, changing all appropriate assembly references in Visual Studio for the projects. Now when it is deployed, we get the following error on any page we hit on the site:
Could not load file or assembly 'Microsoft.TeamFoundation.WorkItemTracking.Client.Cache, Version=10.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I can run from my localhost and development workspace without any issues, so something with the build seems to be amiss. After examining the build that TFS pumped out, three more assemblies are being included in the build for the TFS SDK that weren't there before:
Microsoft.TeamFoundation.WorkItemTracking.Client.Cache.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine.dll
I can't figure out why these are being pulled into the build now. We don't directly reference these assemblies in any project. The code for pulling the comments from TFS didn't change, only it's assembly location. No TFS upgrades were performed. Bottom line - we added a class library where the code now lives and it seems to want some other assemblies that it didn't want before when it lived in the App_Code folder. My best guess is that TFS pulls these in as dependent assemblies for the others during the build, but I'm not sure why.
Hits online for similar errors generally revolve around 32/64 bit issues. I checked Config Manager and all the projects in the solution are set to use Any CPU, which seems right to me, and we have 32-bit applications enabled in IIS on the server.
My apologies for the length of this post, but I wanted to provide what I thought were the pertinent details. Any thoughts would be greatly appreciated. Thanks.
Public Function GetChangesSinceDeployDate(ByVal lastDeployDate As DateTime) As List(Of TFSChange)
Dim tfs As New TfsTeamProjectCollection(New Uri("http://tfs.proviadoor.com:8080/tfs/entrylink"))
tfs.EnsureAuthenticated()
Dim vcs As VersionControlServer = CType(tfs.GetService(GetType(VersionControlServer)), VersionControlServer)
Dim versionFrom As VersionSpec = GetDateVSpec(lastDeployDate)
Dim versionTo As VersionSpec = GetDateVSpec(Now)
_changeList = New List(Of TFSChange)
Dim changeSetIds As String = ""
For Each projectPath As String In _projectPaths
Dim results As IEnumerable = vcs.QueryHistory(projectPath, VersionSpec.Latest, 0, RecursionType.Full, "", versionFrom, versionTo, Integer.MaxValue, False, True)
For Each chgSet As Changeset In results
If Not chgSet.ChangesetId.ToString().InList(changeSetIds) Then
_changeList.Add(New TFSChange(chgSet.ChangesetId, chgSet.Committer, chgSet.CreationDate, chgSet.Comment))
changeSetIds.Append(chgSet.ChangesetId.ToString(), ",")
End If
Next
Next
Dim sortedList = From chg As TFSChange In _changeList _
Select chg _
Order By chg.CommitUser, chg.ChangeDate Descending
Return sortedList.ToList()
End Function
Private Function GetDateVSpec(ByVal versionDate As DateTime) As VersionSpec
Dim dateSpec As String = String.Format("D{0:yyy}-{0:MM}-{0:dd}T{0:HH}:{0:mm}", versionDate)
Return VersionSpec.ParseSingleSpec(dateSpec, "")
End Function
The message "program with an incorrect format" does suggest a 32/64-bit issue.
The problem is that "Any CPU" code will launch in the highest bit-ness it can: in your case, 64-bit, because all of the assmemblies referenced at launch time are 64-bit (or at least Any CPU).
Some combination of lazy assembly loading/JIT in .NET means that the TFS assemblies aren't actually loaded until you hit your method call. By this time, your application is already committed to run as 64-bit, and so loading the 32-bit TFS assemblies fails - you can't mix bit-ness in one process. Permitting 32-bit apps in IIS isn't enough: you have to ensure that your application really does run as 32-bit by changing the compilation settings. In this case "Any CPU" is actually the culprit, because it's allowing your code to launch as 64-bit.
I say "some combination" because I'm not sure of the precise detail, but I have seen exactly the same issue in a console application, compiled as Any CPU and referencing the TFS DLLs. The solution was to compile the entrypoint assembly as 32-bit. Where this same code was consumed in a web service, we ended up shelling out to a separate process so that the web app wasn't reduced to 32-bit too.
After adding my existing Tridion 2009 event DLL's (compiled on 2011 server) to bin directory and registering DLL in Content Manager Config file the GUI now returns the error below. I have checked event logs, Tridion logs etc for more details on the 'missing dependency' anyone any ideas?
Could not load file or assembly 'Tridion.Extensions.Events, Version=1.0.20.521,
Culture=neutral, PublicKeyToken=ecb60dbe3cbb7440' or one of its dependencies.
The system cannot find the file specified.
Unable to get LangID of User (tcm:0-2851-65552). Initialization of the extension
'C:\Program Files (x86)\Tridion\bin\Tridion.Extensions.Events.MDO.dll' failed.
System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly,ObjectHandleOnStack)
System.Reflection.RuntimeAssembly.GetExportedTypes()
Tridion.ContentManager.Extensibility.TcmExtension.LoadExtensions()
Tridion.ContentManager.Extensibility.TcmExtension.LoadExtensions()
Tridion.ContentManager.Extensibility.TcmExtension.InitializeExtensions()
Tridion.ContentManager.Extensibility.EventSystem.DeliverEvent(IEnumerable`1,TcmEventArgs,EventDeliveryPhase)
Tridion.ContentManager.Extensibility.EventSystem.DeliverEvent(IdentifiableObject,TcmEventArgs,EventDeliveryPhase) Tridion.ContentManager.IdentifiableObject.Load(LoadFlags,Boolean)
Tridion.ContentManager.IdentifiableObject.Load(LoadFlags)
Tridion.ContentManager.BLFacade.IdentifiableObjectFacade.Read(UserContext,String,XMLReadFilter) XMLState.GetPropertyElem XMLState.GetProperty User.LangID
It looks like you have two assemblies: Tridion.Extensions.Events.dll and Tridion.Extensions.Events.MDO.dll. Since you refer to TcmExtension DLLs by their full path in the Tridion.ContentManager.config, you cannot have one that depends on another in the same directory.
The solution is to put the "shared library" (probably Tridion.Extensions.Events.MDO.dll for you) in the GAC.
Fortunately, .NET assemblies contain all the dependency information you need in their metadata. Faced with this problem, I would generally try to open up the assembly with a tool that can read this, for example, ILDASM, or IlSpy. That gives you a concrete list of things to look for, instead of the vague and mysterious "or one of its dependencies".
An alternative approach is to use FUSLOGVW to monitor where the .NET runtime is looking for assemblies.
Going mad here.
I'm new to windows dev and I have registered my dll in the GAC.
I get a message saying "Assembly successfully added to the cache" and I can do a
Gacutil /l "its name" and see it there
But when I try to instatiate it in Classic asp like so:
Set TemperatureComponent = Server.CreateObject("comInteropTutorial")
I keep getting the error:
"Server object: 006~ASP 0177~Server.CreateObject Failed~800401f3"
which I believe means it can't find it?
I have also tried to do the same things for other components that were already in the Global cache like:
Set TemperatureComponent = Server.CreateObject("XamlBuildTask")
and the same thing happens.
Before adding the dll to the GAC, I did the following:
I compiled the dll in Visual studio 2010 and did the following:
Click on project
Application - sign the assembly
Build - register for Com interop
Signing - sign the assembly use a file that you have created using sn command (sn –k )
I'm truely stuck now, can someone recommend anything?
I'm on windows 7 here, dunno if that matters... 64 bit 32 bit etc?
I'd happily step through a process that helps me determine the cause of this problem if anyone can recommend one?
Looks like it is answered in another post: Accessing a .NET Assembly from classic ASP
...make sure your .Net assembly is set to
be COM Visible.
In Visual Studio, does the component show up in list of objects under the 'COM' table if you try to add it as a reference? Does the assembly depend on other assemblies or DLL's?
Just a guess here, sounds like either the regasm step is missing which adds the appropriate stuff to the registry, or in my case recently, IIS was running in 64bit, but the assembly was compiled for 32bit.
I am using a COM dll in my .Net web application. This works fine on multiple different machines.
However on one particular machine I get the following error:
Unable to cast COM object of type 'CServer.CApplicationClass' to interface type 'CServer.ICApplication'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CF0DFA28-046B-4C7D-8AA9-F4B7477D8CAE} ' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
I have registerd the dll using the regsvr32 command.
I have also created a COM+ application for this dll.
Running a search through the registry
I can find the key in numerous places.
I have also tried unregistering the dll and deleting all referneces on the computer to this dll. And afterwards re-adding the dll and re-registering it.
I have written a simple windows script file which tests the dll. This works fine. However the problem exists in my .net project which is running in iis.
Can anyone help me with this?..
If you need anymore info please leave a comment. Thanks.
I had a similar problem, with the "TYPE_E_CANTLOADLIBRARY" message.
Background:
I had a project which used Interop.ReferenceA.dll. This file was created using tlbimp ReferenceA.dll /out: Interop.ReferenceA.dll.
Solution:
When I took a look at ReferenceA.dll using RegDllView I noticed that ReferenceA.dll had a subclass, which was the IID shown in the error message.
I looked around in the source code of the subclass and noticed that it had a dependency to Interop.ReferenceB.dll.
Turns out that the subclass needed Interop.ReferenceB as a type-library to work. So I ran this:
regasm /tlb:Interop.ReferenceB.tlb Interop.ReferenceB.dll (the 32-bit version of regasm was used.)
And the error went away.
Make sure your AppPool is set to x86. Also make sure your assembly is targeting only x86.
I was having a similar issue. First got Access Denied, which after some looking around was resolved, only to be faced with this error message (TYPE_E_CANTLOADLIBRARY). Mind that I'm running a COM+ Component on Windows 7.
After some fruitless attempts which involved messing with the registry, my workmate and I found a way of getting it up and running:
1) Unregister your dll (regsvr32 -u dllname)
2) make sure your references to the dll are cleared up from registry (backup first)
3) Create an empty com+ application (server app) in Component Services
4) Copy the application id to the clipboard
5) go to "c:\program files (x86)\Complus applications" and create a folder with the id on your clipboard
6) copy your dll into that folder and register it
7) Go back to your Component Services and add the component to the app you created using the dll on "c:\program files (x86)\Complus applications{*app id*}"
that did it for me. Hope it helps.
I had a similar problem where the error was triggered on my PC but not on that of other developers.
It turns out that I had been testing an automatic build process on my PC that had updated the version number of the assembly, thus registering the TLB in the registry with a version number higher than the one we were normally using.
When trying to get the interface, the server was consistently using the wrong TLB information leading to the wrong assembly. Once I deleted the higher version entry in the registry, it worked fine.
Now we just have to ensure the build process is not going to cause that issue again. :)