I've got a multi-project solution (VS2013 Express) and like an idiot I assumed that running update-package would only update the packages in the current project.
This caused all kinds of nastiness, the majority of which I've worked through and resolved. I'm now left with the following the MVC project and I'm stuck:
the Default Namespace is no longer recognised in the IDE
I have lost Intellisense in the project
the Refactor options are not available
SimpleMembershipInitializer has red squiggles indicating it can't
be found
However the solution builds and appears to work without issue - I'd appreciate some pointers as to where to look to clear the above.
I found a solution in this instance, it has happened a few times since and simply unloading the project and reloading it has resolved the issue every time
Related
I have a project that is coming up with 5 BC30002 errors, type 'typename' is not defined. However, when I double-click the error to open the offending line of code, intellisence does not show the line as an error, and in fact, when I clear out the name and re-type, intellisence finds the type for me.
One thing I have noticed is that the referenced library in question appears correctly if I remove it and add it back in. It shows the version number of the DLL and "Copy Local" is showing as "True". After I build the project, I then see the version number as 0.0.0.0 and local path is set to "False" (see below). I think this is the root of the problem as it seems that during the build process, it loses track of this DLL.
Any ideas on what might be causing this?
Have you tried deleting your VS folder?
A bit late of a reply but I just had the same issue and resolved it by updating the NuGet packages for the typename. For some I had to then downgrade the packages to their original version (some things were no longer working/present in the newer versions) but in the end the solution build and compiled just fine.
I'm trying to download and run working branch onto a second machine from Azure DevOps (formerly VisualStudio.com).
Main machine (VS2017 Pro):
SolutionABC builds and runs perfectly
Branched to SolutionABC-Branch with small changes (external to this issue)
SolutionABC-Branch builds and runs perfectly
SolutionABC-Branch checked in
Second machine (VS2019 Pro):
SolutionABC downloads, builds and runs perfectly
SolutionABC-Branch downloads, but won't build:
Tracing the errors back through the Errors dialog, I get this:
Warning BC40056
Namespace or type specified in the Imports
'Microsoft.IdentityModel.Clients.ActiveDirectory' doesn't contain any
public member or cannot be found. Make sure the namespace or the type
is defined and contains at least one public member. Make sure the
imported element name doesn't use any aliases.
A quick Google search leads me here, so following the instructions there are indeed some issues:
Firstly, how can I solve this please?
Secondly, how does this happen when the parent solution from which this is branched runs perfectly on this machine?
Update
It appears that many of the project references (both to other projects in the solution, and also to Microsoft DLL's) are also missing. Through desperation I xcopied the Microsoft DLL's from the initial project to the branched project. This has fixed the issue, but my questions are still unanswered...
Solution
The problem turned out to be the file/path length limitation of VSTS/TFS. Relocating my local repo to a shorter directory name (e.g. C:\TFS) fixed the issue.
Missing DLL files in \bin folder after downloading fully-working solution to a second machine
AFAIK, this issue should not related to TFS/Azure Devops, it is more related to the small changes or the environment settings. Although you think it is (outside the current issue), it may cause the this issue to arise where you can't see/think it.
To resolved this issue, we need to troubleshooting it:
Since the parent solution from which this is branched runs perfectly on the Second machine (VS2019 Pro), we could create a new branch without that small changes, then check if still have this issue?
Then, add those changes and check if you have this issue again.
Note: Try to remove the references from the SolutionABC-Branch solution on the second machine and add them back to check if this issue has been resolved.
Hope this helps.
How to solve this:
Use the nuget package for the Microsoft.IdentityModel.Clients.ActiveDirectory
What is causing this:
I would bet that this is pointing out a discrepancy between those two machines. Look in the directory on box 1 listed in the properties of the reference and check that the assembly is there. Verify it is in the same path on box 2. Also check the GAC on both machines. VS/MSBuild tries to be as smart as possible when looking for those assemblies and if the hint path says one thing, and it isn't found there, but the assembly is registered, the build will go through fine.
I am attempting to add a CefSharp control to an AnyCPU project. I have followed the instructions here: https://github.com/cefsharp/CefSharp/issues/1714 and I thought I had everything working correctly. I pushed my changes to to SVN and then checked out a clean copy.
The first time I attempted to build using that clean copy, I received this error:
error MC3074: The tag 'ChromiumWebBrowser' does not exist in XML namespace 'clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf'. Line 18 Position 14.
as a result of this error, several other libraries fail to compile. If I attempt to build again, everything compiles fine.
I ran a diagnostic build, and, it appears that the CefSharp packages are in fact being installed from NuGet prior to this error and, the error occurs during MarkupCompilePass1.
This seems very, very similar to this issue: https://github.com/dotnet/project-system/issues/4158, however, in that case, it sounds as if the problem was resolved by switching from package.config to PackageReference, but, that approach did not seem to fix my error.
I have read https://www.xavierdecoster.com/post/2014/03/06/migrate-away-from-msbuild-based-nuget-package-restore.html as amaintland suggested in the issue I mentioned above, and, unless I'm misunderstanding, it's not a solution that I can use. For the time being, out continuous integration runs on CruiseControl (which isn't mentioned as a tool that supports automatic package restore out of the box), and we're stuck on VS 2013.
Right now the only option that I can find that seems like it might work is checking the NuGet packages into SVN. This is a last resort solution for me, but, lacking a better option, I don't know what to do.
If anyone has any insights or suggested steps, I would really appreciate the advice.
I'm getting a strange warning when hovering over an OracleConnection object in visual studio. It doesn't seem to stop my website from working fine, but the warning bugs me.
It seems that the class and Oracle.DataAcces.Client namespace is both visible and not visible to my project at the same time.
Here are some pictures:
I have no idea what is causing this; I already have the Oracle.DataAcces reference in my project references. What I suspect that is happening is a bug that would cause my project name to interfere with my namespace, but that doesn't seem to be it.
I tried changing my namespace name and project name to different things, and I still get the same result.
And for some reason the project shows up twice in the navigation bar:
Did you check if the version of the Debugger matched with the version of the Oracle.DataAcces.Client library? That is, for e.g., if you're using x64 bit version Debugger then you should make sure the dll file is also x64. I was having trouble accessing this reference today, and this fixed it. Hope this helps!
Update
After some research, usage of the scientific method and throwing things are rotating blades and seeing what sticks this is what I think might be happening, and I think I found a "solution/workaround" to it.
It appears as Visual Studio is trying to add some temporary DLL/reference to a temporary DLL/project containing all the namespaces that aren't my Web Application's Directory.
Here is what makes me think that this is happening:
When opening the Object Browser Ctrl + Alt + J, There are multiple instances of the projectX Project. Using Dot peek I determined that one of them was the compiled version of my project and the other is some weird project without the main namespace (projectX):
Cleaning the project sometimes work, but the best solution so far has been to go into the solution and files delete the bin and obj folder from my project folder and restart visual studio.
Only using the projectX namespace with no sub-namespaces doesn't fix the problem all. The additional projectX instance in the object browser contains the same thing as the normal one, minus the files and web page objects in my main directory.
So here is my solution:
Create a class library in the solution and put all your classes in it. Then move the references that your class needs to your new class library. Finally, add a project reference to the Web Application pointing to the class library.
It looks like I manage to find a fix but, but I'm going to have to try it for longer to make sure of it.
Follow up
It appears that the solution I found works very well and won't cause the problem to happen again, therefore I recommend it.
We are really struggling with this error with our nuget packages when we are using TFS. A team member will add a package and it will inevitably not be found when we pull it. In the past, we've manually added the packages but we stumbled upon Package Restore! This is an awesome tool but it doesn't seem to work always as I would expect.
These are the steps I have been taking when a simple "Enable Package Restore" and rebuilding doesn't fix it.
Delete the Nuget and Packages folder from the solution.
Restart Visual Studio
Clean solution
Rebuild solution
Now, this gets me there with probably 90% of the packages but there are still some that won't resolve. The weird part is, I've looked in the packages folder and I SEE the missing package installed after I build/rebuild even though it still shows that it is missing.
So, barring a better method to get these to automatically be restored, is there a way I can force it to look at the package location?
I have seen this too, but so long ago I don't remember how it was solved.
I would carefully check that the specific version listed in the project matches exactly the version that was pulled down into packages. That no hint path or other magic was applied to the assemblies, that they are overridden in some way in the web/application config to look somewhere else or a different, now missing value.