I just created a simple MFC dialog based application in VS2005. Whenever I am trying to add variable to an edit control I am getting this error.
I am new in MFC. Please help me fix this :(
Using: C++98 with VS2005
Did you add any variable(control/value) to any of your control and fortunately you deleted it?
If so, you have to remove the ID for control in resources.h and app.rc and also variable initialized in .h files and used in your cpp files.
It may also cause this problem. But im not sure.
I'm very new to SharePoint development, and I'm just trying to add an XML file to a Feature to reference the XML file content in the feature Event Receiver.
It seems that the general recommendation is to use do so like in this SO question:
How to retrieve data from an XML file in a Sharepoint 2010 Feature Event Receiver?
However, my code does not compile when I reference the RootDirectory property. The error I see is below
'Microsoft.SharePoint.Administration.SPFeatureDefinition' does not contain a definition for 'RootDirectory' and no extension method 'RootDirectory' accepting a first argument of type 'Microsoft.SharePoint.Administration.SPFeatureDefinition' could be found (are you missing a using directive or an assembly reference?
Now, the weird part is that while debugging, I am able to evaluate the RootDirectory property correctly in the Quick Debug window.
Am I missing something obvious? Like I said, I'm completely new to SharePoint.
My feature is scoped to the Web level, and I do have a reference to Microsoft.Sharepoint.Administration in my using statements.
Any help is greatly appreciated, thanks.
It was indeed something very basic.
The solution/project was set as Sandboxed. Just going to the properties of the project (not the property pages but hitting F4 while the project is selected on Solution Explorer) and setting Sandboxed to false will let you compile when you're accessing the RootDirectory solution in code.
Also, a few other properties/method not show up when the solution is Sandboxed instead of marked as a Farm solution.
I colleague of mine asked me to see a dll that he needs to use. So I used the Object Browser on Visual Studio 2012. Now he asked me if I can export like a text version of the dll reference (methods signatures and properties).
Is there a way to do it?
I can already see something like
short get_Param(short sNumParam)
Member of LMLib.ISWKey
on the windows dedicated to the description. I just need to put every method in a single file.
You can do it with a trick and have the IDE generate the definitions for you. Write a sliver of code in the text editor, similar to:
var obj = new LMLib.ISWKey();
Right-click ISWKey in the text editor and select "Go To Definition". You'll get a new text file with the definitions, auto-generated from the metadata.
If it is a COM interface, sure sounds like it with a name like that, then you can run Oleview.exe from the Visual Studio Command Prompt. Use File + View Typelib, select the type library of the COM server and you'll get the auto-generated IDL for the server. Prefer this approach if it is in fact a COM server, you'll get more info, including the [helpstring] attributes.
And of course, don't hesitate to ask the owner of the DLL for documentation. You paid good money for the license to use the DLL.
I'm using VS2010 and in my solution one of my C++/CLI projects references the other. But it can only link correctly when the project being referenced is compiled as a Static Lib.
I read all over that in managed .NET languages, .EXEs, libs and .dlls are the same thing, with a single flag or something like that as difference. Being like that, I can't figure out why I have all these linking errors, since it shouldn't matter how I compile my project.
Well, probably I'm assuming something wrong. If so, how can I reference a .exe project in an other .exe project so I can use the same classes and methods without having to recompile it.
Thanks in advance,
Theo
While referencing an EXE project and loading it at runtime as though it were a DLL is okay for pure managed code, that is not going to work out well for a C++/CLI project. The CRT won't be initialized correctly, there is no DllMain() entry point that will run.
You'll need to create a DLL, use the CLR Class Library project template.
What ever compile or link errors you'll get after that might be secondary. Make sure you quote them in your next question, error messages were designed to tell you what is wrong.
Right click on your project and choose "Add reference..." in the menu.
PS: can you show the linker error messages?
In my project I have a class that is inherited by many other classes. We'll call it ClassBase.
public class ClassInheritFromBase : ClassBase
When ClassBase is being inherited, ReSharper throws an "Ambiguous reference" warning on the ClassBase, and anything inside the new class that inherited from ClassBase does not have IntelliSense and gets warnings that it cannot find it.
The project compiles and runs fine.
If I change the namespace ClassBase is in and then change the inheriting classes, they find it fine and ReSharper has no problem, IntelliSense works ... until it is compiled. After the compile it goes back to having the ambiguous reference warnings and everything else.
Has this been seen before and how can it be fixed? I saw an entry in JetBrains bug tracking for an issue just like this, but they closed it as unable to reproduce.
For those who still have a problem with this, (I still get it from time to time) here's the steps I did to get rid of the ambiguous reference warning in ReSharper.
First I went to all my class libraries and made sure that all references to my other class libraries had the Copy Local property set to false.
In the project where I actually got the ambiguous reference warning, I went to my bin catalog and deleted all .dll and .pdb files for all the libraries that had their own project.
After a new build, or in my case "update reference" on the .dll files in VS, the errors from Resharper were gone.
I'm using Resharper 5.1 in Visual Studio 2008 with only a reference to the dlls I'm using which is why I had to "update reference"
I'm using VS 2012 and ReSharper 7 and sometimes I found the same behavior. These are the steps that worked for me:
Clean Solution
Close Visual Studio
Go to the root folder of your solution and find a folder called _ReSharper.[Name of your solution] and delete it.
Go back to Visual Studio, open up your solution the folder gets recreated and no more "ambiguous reference" errors after that.
I've seen this bug in ReSharper 4.1. It happens when the base class is in the App_Code directory. I don't know how to fix it; it is very annoying, but the code still compiles though.
You may really have an ambiguous reference. In the project where the ambiguous reference error occurs, make sure to check in your project references. You might have the same reference twice but scoped through different namespaces. In my case there were two, but with different paths (example):
XXX.YYY.ZZZ.myassembly
ZZZ.myassembly
Make sure you don't have this kind of thing in your references.
This is a bug in ReSharper 4.1 and is fixed in one of the later nightly builds.
Download the last nightly build at
http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+4.0+Nightly+Builds.
ReSharper -> Options -> General: Click # Clear Caches # button.
For me it was a matter of me not using the solution folder for caches. Changing it from the TEMP location to in the solution solved my problem.
I deleted the _ReSharper.SolutionName folder found in the root of my solution and restarted.
I was using Visual Studio 2010 with ReSharper 5.1... Clearing the cache DID NOT help (ReSharper -> menu Options -> General -> #Clear Cache#).
With R# 2019.2.3 and using the new SDK .csproj format, which splits references between .NET references, NUGET packages, and project dependencies, there is a tendency for R# to still add a project reference under Assemblies, even when there is already a project reference under Dependencies. This results in the ambiguity error but can be hard to notice since the reference is in two separate places. Look for any project references that appear under Assemblies and remove them.
I was experiencing the same problem with references to C# classes in the AppCode folder.
I resolved this by upgrading my ReSharper to version 4.5 (from version 4.1).
It was a very simple upgrade, I just had to get the latest version from the JetBrains website (http://www.jetbrains.com/resharper/download/) and run it.
I did not have to uninstall the previous version (v4.1).
I did not have to re-enter my existing licence key.
All references are now recognised correctly and I can naviage to the classes as expected.
I encountered the same problem. The issue I had was caused by a custom build provider (from an open source library I'm using called PageMethods) and the fact that all my .aspx pages inherit from a BasePage class which lives in the App_Code folder.
I couldn't get any build of ReSharper to work with my project (4.1.933, 4.1.943 (latest) or 4.5). The fix in the latest ReSharper build fixes the "Ambiguous Reference" problem, but breaks the custom build provider.
The only way I could get both the build provider and base classes to work with ReSharper was to put the Base Classes into a separate class library.
The following are the logged Jira bugs that seem to relate to this issue:
False "Ambiguous reference" for
symbols from App_Code
Custom build provider may generate partial
class with second part residing in
app_code
I had same problem with ReSharper 5.1 and solved it by restarting Visual Studio 2010.
Using VS 2013 Premium & Resharper 8.1, and was getting this problem on an ASP.Net project.
The solution that worked for me:
Do a clean Solution.
Open references for the offending project
On each reference that refers to another project in the solution, set Copy Local = false.
Attempt a Rebuild Solution. You will likely get unresolved reference errors - that's normal.
Set each reference back to Copy Local = true (where appropriate)
In VS2022, simply cleaning the solution resolved the errors for me.