The task factory "CodeTaskFactory" could not be loaded from the assembly "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Build.Tasks.Core.dll". A required privilege is not held by the client SkyOnTheWay.Toolkit.Test
=> This occurred all of sudden. I was compiling OK. After changing some code and tried to build again, all of sudden it fails with above error. Cannot go further.
I updated all nudget packages, updated visual studio 2019's updates available, restarted computer several times.
Nothing works. Those answers out there internet are similar but all are little different and nothing worked.
I use VS 2019 and was building Universal Windows' app.
I further test with new project to confirm it's not code issue.
I added new project - Unit Test App (Universal Windows)
Then, compiled. It's OK.
I installed Win2D.uwp nudget. (1.24.0)
Then, compiled. It causes the Error. Nothing further can be done due to the error.
** I have used Win2D for years and no problem. Now all of sudden this causes and big issue.
Also, the error does not occur on class library.
I heard other people complaining the same issue; No change at all, all of sudden 'CodeTaskFactory' error occurs!
Anyone found a workaround or fix?
When I try to compile any Windows form application project, I get an error saying:
\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2114,5): error MSB3095: Invalid argument. Culture is not supported.
\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2114,5): error MSB3095: Parameter name: name
\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2114,5): error MSB3095: x86 is an invalid culture identifier.
I was using VS 2017 when I stumbled across this error message. After searching the net, I saw that the problem I had was never asked by someone else. So I uninstalled anything related to Visual Studio and installed VS 2019.
With all my efforts to solve this problem going down, I checked if there was a conflict with my application's references and the MSBuild assembly files. This was also not the solution. Right now I am two weeks behind my schedule and yet still have no answers.
I tried changing platform target and target framework, hoping to see a difference but no; nothing has changed.
I also tried other application projects & targets. Here is the result:
Compiling a console application does not raise an error message.
Compiling a Windows Forms application, however raises the same error message with different projects.
The reason to error MSB3095 is actually not totally specific but it may be caused by the directory which your project is in, like it was in my case.
So simply move your project to another directory, that does not consist a non-ASCII character in. It will most likely solve it.
We're trying to set up a Jenkins (build server) job to build our Office add-in based on VSTO. However, I keep getting a strange error that fails the build process after the DLL is copied to the bin directory of the project:
Error 11 The "FindRibbons" task failed unexpectedly.
System.IO.FileNotFoundException:
Could not load file or assembly 'MyAddIn, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its dependencies.
The system cannot find the file specified.
File name: 'MyAddIn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
So the problem is that the "FindRibbons" task, triggered by the Office add-in build target, has successfully identified the MyAddIn DLL as being an Office Add-In, but is not able to locate and load it!
Any ideas? I'd love to be able to debug the FindRibbons task directly but hooking into and debugging the compile process seems a little extreme...
Here are some observations:
In our build server's Fusion logs for binding the MyAddIn assembly it looks like it's looking in the folder where MSBuild.exe lives (C:\Windows\Microsoft.NET\Framework\v4.0.30319\) and nowhere else.
On my dev machine, there is no Fusion log entry for MyAddIn! But the build process succeeds and Kivo works fine.
On both my dev and build machines I also have Fusion log entries for WhereRefBind!Host=(LocalMachine)!FileName=(PresentationCore.dll) and ExplicitBind!FileName=(MyAddIn.dll) which show the binding succeeding.
This error comes up on the build server whether I use Visual Studio or MSBuild from the command line to build the project.
I've ensured that the .NET/MSBuild/VS2012 versions are identical on both my dev machine and the build server and the error still occurs. The only difference seems to be that the build server is running Windows Server 2012 (since it's Azure, and we can't spin up a Windows 7 image).
This has worked for me every time I upgrade Visual Studio - I don't use ribbons.
This worked for my solution, but use at your own risk:
Open the following file in an XML editor (make a backup first): C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets (the v10.0 part may be different for you, e.g., it might be v14.0)
Remove the following section:
<FindRibbons AssemblyName="$(AbsolutePathToCustomization)" TargetFramework="$(TargetFrameworkVersion)">
<Output TaskParameter="RibbonTypes" ItemName="RibbonTypesCollection"/>
</FindRibbons>
Replace all occurrences of "#(RibbonTypesCollection)" with the empty string ""
Save the file and restart the visual studio
If you migrated the project from a previous version of Visual Studio, be sure to remove the ExcelLocale1033 and SecurityTransparent attributes from the AssemblyInfo.cs file (as answered by Swati in this other question)
If the project still fails to build, it may be because your .csproj file has some references to msbuild's tasks of previous versions of Visual Studio. I suggest you to create a new empty Excel AddIn project, and uses the msbuild structure of the new project file as base for your project.
I had this problem. It was apparently caused because I changed the "Copy Local" setting on reference "Microsoft.Office.Tools.Common.v4.0.Utilities" from True to False. ISYN. (I sh*t you not)
I had upgraded a project from VS2012 to VS2013 and noticed that that reference was the only one set to "Copy Local = True". So I set it to false, because it was different. This caused the error. Changing it back to True solved it.
I had the same error message and finally found a fix. The problem stemmed from the VSTO project being targeted for .NET 4.0 (it seems this is the minimum for VSTO4), while also referencing an assembly built for .NET 3.5. The real culprit was that I had a class in the VSTO project deriving from an interface defined in the .NET 3.5 assembly that in turn derived from a .NET 3.5 library interface. i.e.,
using System.Xml;
class MyVSTOClass : IMy35AssembyInterface // This caused the error
class MyVSTOClass : IXmlSerializable // This compiled OK
using System.Xml;
interface IMy35AssembyInterface : IXmlSerializable
The fix was to update the .csproj to explicitly reference the older version of System.Xml.dll and System.Data.dll which would otherwise default to 4.0 and conflict with the 3.5 assembly references.
<Reference Include="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<!--<Aliases>Data2</Aliases>-->
<HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
<Private>False</Private>
</Reference>
<Reference Include="System.XML, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<!--<Aliases>Xml2</Aliases>-->
<HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
<Private>False</Private>
</Reference>
For those who need to simultaneously reference both the newer and older versions of a DLL, note that it is in theory possible using:
extern alias XmlDll1
using XmlDll1::System.Xml
See http://geekswithblogs.net/narent/archive/2008/11/11/126940.aspx for more info.
This problem can also be caused by adding a reference to an unsigned assembly to a signed/strong named add-in project. In my case I added the RestSharp Nuget package and started receiving this error on build as soon as I referenced RestSharp in code. After some digging I noticed that RestSharp was the only unsigned assembly in the project references. If you have this problem, there are 3 possible solutions:
In the case of RestSharp, I found that there was a signed version available on Nuget - searched for "restsharp signed" and installing that solved the problem.
If you have access to the source code, you can configure Visual Studio to build a signed version of the assembly in the Project Properties page.
If you do not have access to the source code, you can sign the assembly with your own key by following these instructions.
I had the same error and none of the answers from the internet help me fix this problem. The reason why I was getting that error is because I was referencing an assembly of type Console Application. I changed that assembly to be of type ClassLibrary and I did not got that exception any more.
Also I would only get that exception when inheriting from a class that was located on my ConsoleApplication. It took me forever to figure it out.
May be a little late here, but I just resolved this for myself - after following numerous suggestions (via google) all of which did not solve my problem I manually went down the line. Turns out I had compiled a set of libraries with a dependent assembly with a lower version (not the latest). In my main project I also had a reference to this dependency but it was pulled via nuget and was at the latest & greatest version. For some reason VS.NET couldn't figure that out and would completely trip out and drop the error you posted. Once I updated the set of libraries to the latest version of the dependency all worked as normal.
The crazy part is - it worked fine initially and then out of nowhere the issue came about. Hope this helps someone along the way.
After enabling Fusion the output showed that it was looking for the assembly in the msbuild/ folder.
I just encountered this same situation today, futzing around for a bit, restarting VS and then rebooting my machine without any success. Than one warning popped out at me - One of my dependent assemblies was not strong named. Setting that assembly to be strong-named solved the problem.
I had the same issue, and even after reading KKG's answer I could not resolve mine.
It turned out to be much simpler for me, but not less frustrating and time consuming. I was working in a Win8.1 VM which does not ship with .net3.5 by default. My .net4 VSTO4 project was referencing an assembly that requires 3.5 somewhere. The same project compiled find on my other VM which was Server2008 and had 3.5 enabled.
In my case, the cause for this error was the mere existence of a field of a generic value type in the assembly (not kidding), e.g.:
class Foo
{
ImmutableArray<int> foo;
}
Workaround (if the additional indirection is acceptable performance-wise):
Wrap the value type in a reference type. This can be done generically with something like
public sealed class Box<T>
{
public readonly T value;
public Box(T value)
{
this.value = value;
}
}
then foo can be of type Box<ImmutableArray<int>>.
I have experienced this same issue with an add-in for Outlook.
The solution for me was to set Embed Interop Types to True on my reference to Office.dll.
This however caused the add-in to crash during startup with an Access Denied on Microsoft.Office.Interop.Outlook. I fixed that issue by setting Embed Interop Types to True on all references to Microsoft.Office.Interop.Outlook.dll as well.
This error can be caused by a clash of dependency versions. For example:
YourAddIn
-- OtherLibrary v1.3
-- BaseLibrary v1.0
-- BaseLibrary v2.0
If a newer version of BaseLibrary v2.0 is released and updated in your project, however this version introduce a breaking change in your other dependency OtherLibrary, you will see this exception because OtherLibrary is still trying to find the old methods that doesn't exist in newer assembly.
Update OtherLibrary with the latest packages will resolve this clash of dependency versions.
This can also happen if the Microsoft.Office.Tools.Outlook.v4.0.Utilities reference is set to <Private>False</Private>.
<Reference Include="Microsoft.Office.Tools.Outlook.v4.0.Utilities">
<!-- Required for FindRibbons task -->
<Private>True</Private>
</Reference>
Using Visual Studio 2010 to build a setup project that installs a Windows Forms application .Net 4.0 C#. It has worked fine for ages but now when I'm trying to install the finished setup file, I'm getting this error message:
Error 1001. Unable to get installed types in the "Path" assembly. -->
Unable to load one or more of the requested types. Retrieve the
LoaderExceptions property for more information.
I have been searching for answers for over 4 hours now without finding anything. This problem just came without me doing anything. Last time I build the install file was like 2 weeks ago and there was NO problem at all. I haven't deleted any reference or any code that have anything to do with the setup project.
How could this problem appear from nothing and more important, how do I fix it?
Based on the error message in your second comment, it appears that your SysDir.exe assembly has been added as a Custom Action with the InstallerClass property set to true, but either no installer classes could be found in the exe or the exe could not be loaded due to missing dependencies.
You can see the list of Custom Actions by right-clicking on the installer project, selecting View and then Custom Actions.
If your exe does not can an installer class, then you can remove it from the list of custom actions.
If it does contain an installer class, then the issue is going to be missing dependencies. If fuslogvw doesn't work for you (it has always helped resolve this kind of issue for us), you can carefully review the list of references in the exe's project and compare them to what is listed in the installer project.
The other trick that we use is to examine the install directory while the error message is displayed on the screen. We can often see that DLLs are missing by doing this, usually because the path was entered incorrectly in the DLL entry within the installer project or because a condition was set incorrectly.
Have the same error today. For me it was the project type of the class library.
I noticed that the pucture on the guide I was following had selected Class Library (.NET Framework) instead of just Class Library.
Creating the correct project type fixed the error.
https://nhvu1988.com/posts/how-to-create-msi-installer-using-vs-installer/
For about 2 weeks now, I have been unable to run any UnitTests (built in VS unit tests) for a project. Previously everything worked fine. The error message is:
Could not load file or assembly 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\MyProjectName.XmlSerializers.dll" or one of its dependencies.
The project references System.Xml.Serialization and uses the XmlSerializer class; just like many other classes/projects I've written. For some reason, only this project is affected. It builds fine, runs fine, I just can't run my unit tests.
I've checked the directory, and all the dlls in that directory are Microsoft dlls. The dll that it is looking for obviously is not a Microsoft dll.
Anyone have any ideas?
Edit:
It apparently has something to do with using the XmlSerializer and it generating that file automatically instead of using sgen.exe. Here is a link to the MSDN article. From what I've been able to find, it has something to do with using the serializer with generics. None of the sources I've found seem to offer any way to make it actually work.
First enable loader logging (using FUSLOGVW.exe from the SDK) to confirm what is not being found.
Then use Reflector on all your assemblies to find the one that is trying to load the non-existent assembly. If you find no such assembly it must be being loaded dynamically, in which case attaching to AppDomain.AssemblyResolve should allow you to identify where.
try to copy all your source files somewhere, then delete the project and try to make it from scratch. Maybe something happened with project dependencies
Is your computer 64bit? I got the same error when trying to run a 64bit dll with NUnit that was set to work as an x86 assembly (using corflags).
You can probably find out from the error message (use FUSLOGVW.exe lick Richard suggested).
If that is the case you can either sent the dll or NUnit to run as the correct assembly using corflags.
Solution
As it turns out, the problem was with VMWare. I installed the latest version of VMWare, and it installed it's tools to debug in a VM. Something it installed or changed caused this problem. When I uninstalled VMWare, the problem went away. So, I reinstalled VMWare without installing it's debugging capabilities and the problem did not come back.
Workaround:
I still have no idea why this problem suddenly started occurring, but I found a hack to make it work.
I had to go to project properties => Build Events and add this line to the Post-build event command line:
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" "$(TargetPath)" /force
This forces VS to generate the file. I then had to copy that file manually to the directory it was looking for it in:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies"
Now it I can run my tests and step through them. The problems I have now are 1) I have to remember to copy the dll to that directory every time I change something in the classes that I am serializing, and 2) I now get a ThreadInterruptedException when a test finishes running; thus 3) I can only run one test at a time.
Not a good solution, but at least I can limp through. Unfortunately, redoing everything, as Nikita Borodulin suggested, is not an option.