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.
Related
When trying to open an older solution in VS2017 there is an old Unit Test project that is giving me a problem when building.
I keep getting the following error when building this test project:
Could not load file or assembly 'file:///C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' or one of its dependencies. The system cannot find the file specified.
I checked the project's references and it appears to be referencing Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Additionally there are no code errors. How could I ever figure out if it is one of its dependencies that it can't find?
I had a similar issue (with the additional message The "BuildShadowTask" task failed unexpectedly) with a project originally developed with VS2010, and got to spend the last few hours learning about yet another legacy facet of the build process.
There is a good chance that you are dealing with private accessor files (.accessor), which were deprecated in VS2012 (original source). This was foreshadowed in an announcement from the VS2010 team that they were no longer working on these features.
There is also a chance you're just dealing with erroneous refs to the wrong version of UnitTestFramework, but a NuGet restore should fix this. If not, see this GitHub thread for a possible fix (manually change the ref to the public folder), or move to the new MSTest.TestAdapter and MSTest.TestFramework packages (see MSDN support thread).
Solutions
A. Edit the unit test .csproj and change the item Include references from Shadow => None:
<Shadow Include="Test References\namespace.accessor" /> to
<None Include="Test References\namespace.accessor" />
B. Better yet, simply delete all the .accessor files from the unit test project's Test References folder.
Ideally, you would also rewrite your unit tests to remove references to private methods, either by re-architecting to separate concerns or by changing properties to internal and using "friend" with the InternalsVisibleToAttribute.
For those who need to continue supporting testing of private methods for some reason, the same post provides the following suggestions to the logical question "What is available for me then?":
For those who wish to continue testing internal APIs, you have three options:
Use the Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject class to assist in accessing internal and private APIs in your code. This is found in the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll assembly.
Create a reflection framework that would be able to reflect off your code to access internal or private APIs.
If the code you are trying to access is internal, you may be able to access your APIs using the InternalsVisibleToAttribute so your test code can have access to the internal APIs.
However, there is not any good replacement for Code Generation for the new features added by the lanugage teams. You may create the TestMethod stubs and then remove the internal code. You only need to keep the stub itself.
Further reading / sources that helped me piece this together:
VS 2005 ASP.NET explanation of accessors
2008 blog article explaining how to work around this for build servers
MSDN forum thread with discussion on accessor purposes, implementations, and workarounds. Start about 1/3 down.
MSDN BaseShadow docs
MSDN PrivateObject class
Right click the project references folder. Add reference > Assemblies > extensions. Check Microsoft.VisualStudio.QualityTools.UnitTestFramework 10.1, and uncheck any older version.
This is related to Visual studio Enterprise 2015, add new load test was failing: and spiting as "Unable to find assembly 'Microsoft.VisualStudio.QualityTools.LoadTest, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Due to Assembly installed in public assemblies shows as version 10.0.0.0 which is missed in GAC,
GAC had only 10.1.0.0. Once GAC updated with 10.0.0.0 and restart VS 2015. should resolve the issue similar to this.
Some more detail for better reasoning, System Assembly path and project path
DLL path
......\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
.CSProj reference version
I had a same issue while I was upgrading project to .Net4.8 in Visual studio 2022 earlier we were using Visual studio 2017.
Error:
The "BuildShadowTask" task could not be loaded from the assembly ***\Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll. Could not load file or assembly 'file:///***Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll' or one of its dependencies.
Solution : I removed ".accessor" files from project as that is being used for accessing private methods(most probably accessor is depricated). Then we used "PrivateObject" class for accessing private members in UnitTest.
Later we updated Unit Test case. Code references could be found from below articles.
Unit test private methods?
Unit Testing: Exposing Private Members
I had a similar issue (compile project in server Jenkins)
Solution:
Include VS.QualityTools.UnitTestFramework to reference project, whit Pakage Manager:
PM>NuGet\Install-Package VS.QualityTools.UnitTestFramework -Version 15.0.27323.2
https://www.nuget.org/packages/VS.QualityTools.UnitTestFramework
Try to fully uninstall Visual Studio 2017 (not repair). Then download the latest version and install it. Remember to check if MSBuild is added to installation files. Remember to delete folder inside Documents: Documents\Visual Studio 2017. In my case, this simple solution fixed all errors.
I have a Biztalk application that is basically a housing for a schema that other applications are using. I now want to remove this application, but am unable to from the BizTalk Server Admin Console, when I right-click --> Remove I get an error that says
Could not load file or assembly <assembly_name>.dll or one of its dependencies. The system cannot find the path specified (mscorlib)
followed by:
The system cannot find the path specified (Exception from HRESULT: 0x80070003)
So I go to remove the assembly from the Application and get the exact same error. I remove all references to it in other biztalk resources and still the same error when trying to delete the application or resource. I did notice that in the Modify Resouces dialog of referencing assemblies, this rogue assembly is listed as a dependency status of Not Found.
The strange thing is, when Messages come through, the resources which depend on the rogue assembly, still work fine and no errors are thrown (despite them using components of the assembly which shows as Not Found).
I have made sure to check the GAC and the assembly is loaded to it.
So now I have to ask:
where is Biztalk actually looking for this assembly?
is there a way I can just force a deletion of this application?
why does it care if the assembly is not found, when I'm trying to delete it?
why does it show as Not Found, yet still work?
Thanks.
I think the key is "or one of its dependencies." If it's a dependency it may be using the standard windows mechanism for finding a dll. It searches the current directory and the windows directory for them.
"where is Biztalk actually looking for this assembly?"
Look in the 'resources' section of your application in the biztalk management console. It shows a column with the location of the assembly.
I'd stop all the host instances/orchestrations, and then unload all your stuff from the GAC - if messages are actually still going through then stuff is still loaded that is using your schema.
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 have several DNN modules that I wish to update silently, using the portal's built-in module upgrade facilities called from a separate application, in this case a Windows service. I was able to make it all work with version 4.3 of the portal by modifying the DNN source in key areas to allow DotNetNuke.dll to function outside of a web application. I'm now trying to do the same thing with the 4.9.0 source code and I'm having problems.
Everything works fine until DNN tries to read from the database. I have my Windows service project, the DNN library project, and several other related projects loaded in one VS solution (the additional projects are the same ones that are in the main solution file provided with the DNN source). I call PaInstaller.Install in my service to update each module. Execution gets to reflection.vb and then it tries to create a DotNetNuke.Data.SqlDataProvider object based on the type name. It raises an exception when calling System.Web.Compilation.BuildManager.GetType. The exception says:
Could not load type 'DotNetNuke.Data.SqlDataProvider' from assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I read this to mean it simply couldn't locate the DotNetNuke.SqlDataProvider.dll assembly. What's strange is that assembly is in the Bin folder for the DNN library project, and I also have it in the folder where my Windows service is running. The actual SqlDataProvider project is also loaded in the solution. I can't for the life of me understand why the runtime environment can't locate the assembly.
Has anyone tried something like this before, or know what could cause an assembly not to be found while stepping through the DNN source? Am I better off using something other than BuildManager.GetType to get an instance of the SQL provider type?
Chris,
Honestly depending on your needs, I would look at doing this a different way, as this is going to be very fragile with each DNN upgrade that happens in the future.
I'd look more towards using the "bulk install" option that DNN already has. Have your service upload the module zips to the /install/modules folder, then from there, call /install/install.aspx?mode=installresources and you are done!
If you need a third party solution to parse the results, have your windows service go through and pull the HTML response and parse it to validate success.
I'm using Licensed componentone product in my ASP.NET application and spcefically i use C1WebReport1 control from the product.while upgrading C1WebReport1 control from version 2.5.20072.239 to 2.6.20093.53207,i get the error message as
"Could not load file or assembly 'C1.Web.C1WebReport.2, Version=2.6.20093.53207, Culture=neutral, PublicKeyToken=594a0605db190bb9' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
can any one help me to bring complete solution?
Thanks in advance.
Regards
Omprakash
It looks like the new (version 2.6.20093.53207) dll might not be in your bin folder. You can view the version of the dll by right-clicking, selecting properties and viewing the summary tab. Make sure you have the right version included in your project. If you have an old dll.refresh file I would delete it and also go into design view on the form that uses WebReport to regenerate the licensing files.
By the way, ComponentOne just released a brand new ReportViewer for ASP.NET you might want to try out too. If you have a license for 2009v3 you probably will qualify for the free upgrade!