Related
As a part of the Visual Studio 2017 UWP build process, an app called MakePri.exe is run. It is throwing an error in my project but I have no idea why. The command line call is:
C:\Program Files (x86)\Windows
Kits\10\bin\10.0.16299.0\x64\MakePri.exe New -ProjectRoot
C:\AdaptSource\src\Xivic\Adapt.Presentation.XamarinForms\Adapt.Presentation.Xivic.UWP\
-ConfigXml obj\x86\Debug\priconfig.xml -OutputFile C:\AdaptSource\src\Xivic\Adapt.Presentation.XamarinForms\Adapt.Presentation.Xivic.UWP\bin\x86\Debug\resources.pri
-IndexName AdaptSolutionsPty.Ltd.Xivic-Helpdesk -Verbose -Overwrite
The error that it returns is:
error PRI175 : 0x80073b0f - Processing Resources failed with error :
Duplicate Entry.
GENERATEPROJECTPRIFILE : error PRI277: 0xdef00532 - Conflicting values
for resource ''
I have no idea what it is talking about. There is no useful information in the error message. After sifting through a lot of google results, I see that the problem seems to come up when there are references to certain or duplicate DLLs in referenced .NET Standard / PCL projects.
For example:
https://forums.xamarin.com/discussion/103956/strange-build-error-xamarin-uwp
UWP unit test compile errors
But in other threads, at least people are getting a resource name to work with. I've removed as many references as I can. I've used resharper to help. I really need to get a useful error message out of MakePri. Does anyone know anything about this? Is there a way to see what it is stumbling on?
Edit: The issue was that my solution was using two versions of Xamarin.Forms. Once I consolidated the NuGet packages, the problem went away. But, I feel like this is a bug because the error message should be more descriptive. It wastes a lot of time. So, I've logged the issue here:
https://github.com/dotnet/buildtools/issues/1912
I'll leave this open until there is some kind of response at Microsoft.
Consolidate both Xamarin.Forms and Microsoft.NETCore.UniversalWindowsPlatform version for all the dependency projects will resolve the issue. It is mainly due to the Xamarin.Forms latest stable version requires higher version of Microsoft.NETCore.UnivesalWindowsPlatform nuget i.e.,(6.0.1).
The message is missing a piece, may caused by 16299 sdk
please try use 15063 and you may get the right key
I had the same problem, with the exact same error message. My fix was different than yours.
By deleting resources one at a time, until the build succeeded, i found the cause to be in one of my language .resw files I had forgotten to append .Text to the name.
Language A:
"Message.Text", "Hello world"
Language B:
"Message", "Hello world"
This oversight gave me the error you mention in the heading.
The fix for me was to append .Text so the names are identical.
I'm trying to run a .NET MVC application on my local computer that I got from GitHub.
When I hit run on Visual Studio, everything complies and a new browser window opens with the error:
CS1980: Cannot define a class or member that utilizes 'dynamic' because the compiler required type 'System.Runtime.CompilerServices.DynamicAttribute'
The compiler section in the same window, shows the following error:
I've checked on google and this seems to be the same error.
This guy was using a dynamic type himself, on the other hand I'm not using any dynamic type, this is being auto generated by .NET's compiler, and I'm using .net 4.5 which should has support for dynamics.
I tried to apply the same solution (Changing all System.Core references to 4.0)
but the thing is that all of them are version 4.0 already.
Do you have any idea how could I resolve this?
I had a similar error on a project I was trying to migrate. Try re-targeting the framework of the project back a version or two, and once you find a target version where you do not get the error, re-target back to the version you originally had trouble with.
I was getting the same error on a website project targeted for 4.6.2 that was referencing some older libraries, re-targeted it back to 4.5.1 and that resolved the error. I immediately re-targeted back to 4.6.2 and did not encounter the error again.
I had this same issue, but none of the answers here solved it, but did point me in the right direction. I think I didn't update the .NET version on my machine to the newer one. After installing it, I rolled back the targeted framework (as was suggested), retargeted the newer framework, and did a few extra things also:
Reinstalled ALL packages by running this in the package manager:
update-package -reinstall
I also compared my project to one that was working for 4.5 and did this:
Opened my project file and removed all "BCL" related elements.
Uninstalled all "BCL" packages in the NuGet package manager for the project (guess it's not needed moving to 4.5+...?)
Removed an old package version of System.Net.Http, which did not get updated for some reason (see web.config - versions should show oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0").
Have to restart VS.
Rebuild solution.
Error is now gone. ;)
One other thing I did to resolve some other errors was to clear the component cache by deleting all files in here:
C:\Users\{USERNAME}\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache\
[rant] Wasted a whole day with all this. Thanks to MS for stealing one more day of my life fixing senseless issues that should never be. Every time I upgrade I always get a wonderful surprise, and a lovely game of fix the red herring. Would it not hurt to detect these conflicts for those upgrading old projects? Perhaps better error traces when things go wrong? I doubt it would be that difficult. Perhaps even something like AsmSpy, but more advanced, built in to VS? [/rant]
Saw this in VS 2019. I excluded and re-included the problematic file (in my case _Layout.cshtml) and that fixed the problem.
I got this error suddenly a couple days after updating to VS2015.3 using 'traditional' MVC app (not new .NET Core / vNext app).
Turns out this error can be a complete red herring.
Make sure:
You haven't got any other errors at all
You've checked the output window for any errors that don't show in the 'Output' window.
Make sure you don't have any conflicting references
In my case I had a typescript error that was causing an error and for some reason triggering this weird 'red herring' dynamic error too.
My fix was to go into the .csproj file and update the typescript tools version to 1.8 (need to unload project and edit by hand). As I said this is unrelated to the error, but I mention the specifics because someone else may end up with this same problem.
I believe that 1.7 didn't accept 'None' for the typescript module system whereas 1.8 does, hence the error.
Adding a reference to System.Dynamic.Runtime did it for me.
I hesitate to write this as an answer, but for me the error appeared in a .cshtml file. I closed the page, rebuilt, and the error vanished. Always best to try the simple things first.
I had the same error, there were just 2 unused tables of my databaseset that I had to delete. I wonder why it worked when I manually change sth in an auto-generated code work but after deleting, it worked.
So be aware that such inconsistencies can also cause this error.
My solution was to correct the version of MVC in web.config under Views folder. E.g. the project referenced MVC assembly version 5.2.2.0 but in the Views/web.config file was version 5.2.4.0 (see image).
Image
Tried a few other answers with no luck, but the overall consensus appears to be that this some sort of issue with cached build artifacts or compiler state or something. Here's what worked for me:
Delete the problem .cshtml file, watch error disappear
Open source control and revert the deletion
This error will come because of the different versions of your Sitecore.Web.Mvc.Dll in solution reference folder(Project name->References->Sitecore.Web.Mvc->right click and check properties) and the version of Sitecore.Web.Mvc.Dll in Web.Config in views Folder.
For solving this error you have to make sure that the version of Sitecore.Web.Mvc.Dll is same in both folders.
Thanx.
For my case, I fixed to run the command line "update-package -reinstall" on the Package Manager Controler.
My problem was in the _Layout.cshtml.
None of the solutions above did the trick for me. I am using VS2017 for this project, upgraded an ran into the same message.
I had commented out a 2 lines in 1 comment #* *#
My solution was to comment out each line separately. What a mystery!
A few hours lost on this.
In my server app, I can get File version info this way:
FileVersionInfo currentVersion = FileVersionInfo.GetVersionInfo(filePath);
...but that trick doesn't seem to work in the Compact Framework (I get, "The type or namespace name 'FileVersionInfo' could not be found (are you missing a using directive or an assembly reference?)"
It seems that the "using" I need in my server/Web API (.NET 4.5.1) app is System.Diagnostics, but adding that to my CF app leaves the using statement greyed out (and doesn't afford the resolution of the err msg shown above).
Do I need to add a specific assembly reference, coupled with a particular "using" to get this to work?
Or do I need to use custom CF code for this, such as that found here?
UPDATE
At the article linked to above, it says, "Getting file version info in the Compact Framework is pretty simple – provided the file you want info on is a managed assembly."
So, okay: what is the simple way? I'll try that first, before I go leaping through fiery hoops. And I know this question will seem naive to many, but: Is a custom .exe we have created (an "in-house" app) "native" or "managed"? I tried googling the difference between the two, but didn't find a definition...
It depends what you mean by "version". As with everything, it's not as simple as it may seem. managed assemblies have a managed version, which is what is set in your AssemblyVersion attribute, something like this:
[assembly: AssemblyVersion("3.0.2")]
This is the version that the managed loader uses and the version that ends up in the type names of the types in the assembly. It's really the "important" version number. It's the version you get if you look at an Assembly's Version Property.
However, it's not the version number that you see when you look at "File -> Properties" in something like Windows Explorer.
Explorer looks at the file for native VERSION_INFO headers, which are completely disconnected from the managed version. For a desktop app, it's set using the AssemblyFileVersion attribute. The Compact Framework, however, doesn't have support for setting that version information. You can work around that if you want, but the CF also has no inherent way to read it back. That's why the blog entry you refer to is talking about - getting the native version info.
So you have to figure out which version you're interested in, then follow the path for setting and getting it. Generally speaking, if it's a managed assembly I try real hard to avoid ever dealing with the native AssemblyFileVersion because it's really not useful for much of anything. Instead I just work with the AssemblyVersion. This is true for CF, desktop or Mono.
After I build a few of my references, which are present in the project and accessible through intellisense before the build is performed.
Unfortunately none of my projects are set to target Client Profile, as answered in this thread.
The type or namespace name could not be found
This seems to be the most common cause, does anyone know what else other than this can cause the same issue?
Edit:
The Types that aren't found are all from the referenced DLLs. I have the correct using directives for these and they are present in the resource folder, however they become underlined red after a build (I did try cleaning to).
My initial thought was the framework (the project is on v3.5), but I checked all my resources working or otherwise all where on v2 bar a few (working ones) on v4 which I removed temporarily to make sure we're causing issues.
Unable to access the project from my current location but will post any requested specifics as soon as I can.
edit:
Resolved the issue by deleting all of the custom class libraries... found and rebuilt each of their projects then added the new DLLs back into the project. Stored libraries weren't very organised, so I probably have some confliction between old/new versions.
Have you read the warning in the error list? You might need to install nuget package used by the referenced projects
for me the error warning was
All projects referencing "project file" must install nuget package Microsoft.Bcl.Build.
Are the projects being built correctly ?
Sometimes, you need to manually generate them (right click on them, generate), before being able to run a full build.
I dont exactly know why, but this might be the way to go for you.
~A few simple things to try before getting into more complicated water...
Try clicking:
Build->Clean Solution
Build->Build Solution
If this doesn't work, check your using statements are all there and correct, check your references all still exist.
I had a similar issue today, and I thought I would mention it here in case it helps someone else out. In my case, I have a VB.net Class Library which is referenced by a C# class library. The solution would build fine, but in the IDE, as soon as I started editing a file in the C# project, I would get errors about not finding a reference to the VB.Net library. It turns out that the VB.Net class library had a reference to System.web (lowercase w). I'm not sure how that came about -- but the solution was to delete that reference and replace it with a reference to System.Web (uppercase W).
Make sure all the projects in your solution have the same "Target framework" value
Ok, I have had this one a million times before and it's been answered 1 million +1 times before.
And yet, once again. I have 3 projects, A, B, and C, each a DLL. Each project is .Net 4.0 (not the client build, full 4.0). Project C references A and B. They are referenced as projects, and the output is set to copy locally.
In C, I have two using statements in my .cs file:
using A;
using B;
When I compile, I get the complaint that is cannot find B. A is fine. B depends on A.
What the heck should I do? I've removed and re-added, closed VS2010, re-opened it, looked at the .csproj file. And I just cannot get it. Again, for the millionth time.
Someone please slap enough sense into me that I learn the source of this once and for all!
And yes, this is probably answered somewhere in StackOverflow, but not in any of the top answers I've checked so far. The terms are just too generic to be of use, too many questions where the answer is "duh, add a reference". I'm past that point.
Here are the errors I get. There are 3 kinds, but from past experience, the last one is the true one.
Error 130 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' does not contain a definition for 'Database' and no extension method 'Database' accepting a first argument of type 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' could be found (are you missing a using directive or an assembly reference?)
Error 114 'object' does not contain a definition for <blah>
Error 59 The type or namespace name '<blah>' could not be found (are you missing a using directive or an assembly reference?)
Aha I looked at the warnings, not just the errors, and here is what I see:
Warning 69 The referenced project '..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj' does not exist. AWI.WWG.EXPMRI.MriUpload.Objects
That .csproj file is the "B" in this case. Even though I remove and re-add the project reference I get this. But it feels like I'm getting closer!
Hmm, I just found another DLL, call it "D", which "A" references. When I add it to the project, I start to get the complaint:
----------------
The Add Reference Dialog could not be shown due to the error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
----------------
Could this be related, or just another distraction?
Ok, I found the issue, though I do not understand it.
When I add the reference through the IDE, it adds this to the csproj file of "C":
<ProjectReference Include="..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj">
This does not compile, it WARNS that it cannot find the referenced project, then all those ERRORs happen. But then I change the ProjectReference to the following:
<ProjectReference Include="C:\...\Partners.Connectors.Base.2010.csproj">
... and it works just fine. Note that neither of those paths are anything close to 256 characters. The fully qualified one is only 135 characters. But perhaps the IDE is doing some silly decoration of the path.
The solution has to do with the file path limits in Windows, and they way the IDE translates relative paths into full ones, as explained in this blog.
The immediate solution is to edit the csproj file manually to use the absolute path. Until the reference is re-added, the absolute path will be valid. One day I may shorten my folders, but it's not top priority at the moment.
If you suspect you have this issue, look at the Warning messages from the compiler. I often have these turned off myself, only looking at errors. But the warning about "the referenced project does not exist" was the clue that solved this for me.
In case the other link disappears, here is the link to the MS article.
http://support.microsoft.com/kb/2516078
It is worth noting that this same error manifests for a variety of issues such as client-framework-targeting issues, and is logged as a warning when a reference fails to load. Presumably the reference error is only a warning because if the reference is not actually needed it doesn't matter.
I would make sure that your project has included the references to the assemblies.
I would check that the build order matches your dependencies
Finally, if everything is setup properly, you should see the following Build Order:
Doesn't look like this is your problem, but for completeness, I should add that another thing to check (if your project targets the .NET Framework 3.5 or above) is that the Target Framework for both projects match. If you are linking something that targets the Client Profile from a full version of the Framework, you will also get a 'not found' error:
Go to warning section and resolve all warning and you are done...
The warning section will tell you what all internal dlls dependencies are needed for the project you are referencing to.
I know this isn't the answer to your issue, but the error is quite similar when you are trying to reference a project with a higher .net version than the one you're using. IE: you can't reference something with .net 4.5 from .net 3.5
Basically, this sounds like a missing reference.
Some sanity checks I can think of are:
Are you sure that the project that generates the error is C?
Are you sure you are did not make a spelling mistake in the namespace B in your using?
Can there have been some compilation error in B before compiling C? (That may cause the compiler to fail finding the namespace in B).
Do you have any other compilation error or warning?
Edit
Another suggestion: is the class in the B assembly defined as public?
I got this when updating a project that we normally use via NuGet. I thought if I simply copied the updated built dll over to the packages folder I could test it without having to setup NuGet on my machine, but it wasn't that simple because my app was still looking for the old version number. Hope that helps someone out there.
After many hours of frustration, I discovered the following process to resolve this issue with a VS2017 solution:
Insure that all reference assemblies have been recognized and have current properties.
If assemblies do not show proper reference, right click the entry
and view properties. This action often resets the reference. This
action must be completed for each project in the solution.
After resolving all references, if the error continues, delete the
following:
-The Obj folder
-The Bin folder
-Reference to the offending assembly
-Clean and Rebuild the solution. Errors should occur.
-Re-reference the needed assembly.
The editor should no longer show the namespace error and build should succeed.
Create clean project and test minimal sets of assemblies you use in your project. This way you will be sure if there is something bad in your solution or if newly created project has same symptoms. If so, then maybe VS, .net etc is corrupted or something.
I started getting this error suddenly while trying to solve another problem
I solved this by going to Solution=>properties=>project dependencies and all the dependencies were off for the two projects I was getting a namespace error for. I checked the check boxes and rebuilt the solution with no errors.
I solved this using global::[namespace][type I want to use] in C# 6.0
With VS2017, this issue came up for me when the project in my solution was unloaded.
In my case, I have to check where the "WorkFlow"1 was implemented.
Hence, I compare the framework version of the projects/class libraries that uses this "WorkFlow".
After check that all projects/class libraries uses the same framework, I have to search ".WorkFlow" in the project/class library that was causing the builing error.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Workflow.Targets(121,5):
error : The type or namespace name 'WorkFlow' no exists in the
namespace 'Proyect_to_build' (are you missing a using directive or an
assembly reference?)
It turns out that the .dll that contains "WorkFlow" was missing in the "Reference" folder. Once added the .dll, the project/class library compiled successfully.
Again, in my case, I wasn't using this .dll and I only need compile the project/class library for enable breakpoints in a certain part of the program (where "WorkFlow" is not involved at all), but well, after add it (the .dll with the "WorkFlow" source code), it compiled.
1 "WorkFlow" comes from a legacy code using custom code for WorkFlows.