Created a Test Project using the UiPath.Microsoft.Teams.Activities package (0.5.1) and able to run what we require.
I've then gone to implement this into another project which uses the UiPath.MicrosoftOffice365.Activities (1.14.1) for things like Sharepoint activities - which is now full of errors as there is a versioning issue with the Microsoft.Graph dependency.
UiPath.MicrosoftOffice365.Activities uses "Microsoft.Graph (V 4.11.0.0)
UiPath.MicrosoftTeams.Activities uses "Microsoft.Graph.Beta (V 0.35.0.0)
This now means the same terms are clashing and unable to run - and even use the same PublicKeyToken.
For example:
"The Type 'Team' exists in both 'Microsoft.Graph.Beta, Version=0.35.0.0, Culture=neutral, PublicKeyToken=(removed for security)' and Microsoft.Graph, Version=4.11.0.0, Culture=neutral, PublicKeyToken=(removed for security)'
Has anyone come accross this issue before?
Last time UiPath updated their Microsoft Teams package was back in March 2021 so I assumed this would have been raised previously.
Related
The type 'ObfuscationAttribute' exists in both 'Leadtools, Version=21.0.0.0, Culture=neutral, PublicKeyToken=9cf889f53ea9b907' and 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
I'm just installed Leadtools.Camera.Xamarin NuGet in my existing application and getting the above error. In my existing App I'm using refit nuget as well. and this error came with RefitStubs.g.cs file .why this error occurring and how to resolve the above error in Xamarin.Forms. And the used version is 4.8.0.1821.
I tested by adding the Refit nuget package to our CameraDemo that’s shipped with LEADTOOLS 21 and building the project. This did not cause any compilation errors, even when adding code that uses the Refit classes in the C# code of the project.
This project is available with the full SDK installation under this folder:
LEADTOOLS21\Examples\Xamarin\CameraDemo
This means the problem is not likely related to using Refit and Leadtools.Camera.Xamarin together, but is trigged by something else in your project.
I recommend first to try to update your Visual Studio and its dependencies to the latest version.
If that doesn’t solve the problem, try to isolate the problem is a small test project that contains all the references from your main project but without the actual code (skeleton project, but with full references).
If this skeleton project triggers the same problem, send it to support#leadtools.com with details about the problem and our support staff will investigate it and get back to you.
I am trying to build asterisk , I am using meta-telephony layer provided from oe-layers.
I have faced few issued while building the application "asterisk" for raspberry pi 3 b.
Initially I have build core-image-minimal for Rpi and it worked successfully.
Tried to build few applications like lighttpd, SQLite3 and they worked successfully.
Now i am trying to build an application called "asterisk" whose recipe is in meta-telephony -> recipe-asterisk-asterisk-asterisk_13.5.0.bb , but I have encountered few errors.
Need guidance for below Error i have faced
WARNING: Layer telephony should set LAYERSERIES_COMPAT_telephony in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer telephony should set LAYERSERIES_COMPAT_telephony in its conf/layer.conf file to list the core layer names it is compatible with.
Loading cache: 100% |###########################################################################################################| Time: 0:00:00
Loaded 1370 entries from dependency cache.
ERROR: ParseError at /home/bhavya/dialtronics/yocto/poky-dunfell/meta-telephony/classes/waf-samba.bbclass:4: Could not inherit file classes/pythonnative.bbclass
Please kindly help me to solve the issue.
Thanks in advance
bhavya
As far as I see, the last commit on meta-telephony was from 2017. This is long before the Yocto release Dunfell you would like to use.
Mixing meta-layers in different Yocto releases isn't something you do to have fun.
Or you try to find out what release they where using, and go back to these old days. Or you pick up the work and try to maintain a more up to date meta layer.
And to start it, I thing the pythonnative.bbclass is now python3native.bbclass. Note in Dunfell the Python2 support stopped (as in almost all distro?).
BTW: the version in the meta layer is also quite old (13.5.0). Latest version seems to be 17.5.1.
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.
see screenshot for the express version:
I have an Azure function (in Visual Studio), that triggers correctly an Service Bus event. In its run-method I want to call a method in a custom assembly. This works ok, until I use any method that uses Dynamics CRM assemblies. (I have tried both the assemblies from the downloadable sdk and the nuget package. I get the exact dll it asks for in the error message.
As soon as I call the my method I get the error below. I can run this exact method from a console app. (my custom assembly is a standard (not core) class library...
Additional information: Could not load file or assembly 'Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
This is not an answer, but rather an advice to anyone getting this problem (and its also a rant).
Avoid Azure functions at all cost and use "web jobs" instead when you can. After doing this with webjobs it was as simple as it should be, I have spent a week with different Azure-function-related problems
Cons with Azure functions:
Dynamic crappy scripting language (.csx), which gives you mysterious runtime error messages refering wrong places
Lock-in to azure platform
The usage on the browser editor is a joke unless its a really simple method and the error messages there comes up over and over again in least most annoying way (second to popups) and make you spread out your code
Pros:
Maybe you get a pad on the head from your MS-indoctinated architect for using the latest technologies so he might be able to squeeze in the word "Microservices" on some powerpoint presentation.
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.