Say I have a snippet like this from an external dll that I have to use.
public class DerivedClass : IBaseInterface
{
[JsonIgnore]
[NonOverridable]
[InspectorReadOnly]
public string name;
string IBaseInferface.name {
get {
return name;
}
set {
name = value;
}
}
}
And I am publicising the dll using https://github.com/AzeTheGreat/Publicise so that I can access the private members as public.
But if I use the publicised dll in JetBrains Rider like this:
public class Main
{
private DerivedClass dobj;
public void func()
{
// Jetbrains intellisense shows an ambiguous referencee error
// <AccessTest>\Main.cs:339 Ambiguous reference:
// string IBaseInterface.name (in class DerivedClass)
// string name (in class DerivedClass)
// match
dobj.name = "";
}
}
However, the project builds fine without any errors. And doing the same thing Visual Studio, VS intellisense does not detect any errors at all.
One possible explanation is that, the JetBrains decompiler seems to show the publicised IBaseInterface.name as public but Visual Studio decompiler does not. (This does not make any sense to me, since they are the same assembly and the decompilers are showing different things.)
Is there a way to solve this (I can't change the external DLL) ? Or at least mark the line so that intellisense doesn't complain in JetBrains Rider?
Related
I am trying to develop an extension for Visual Studio 2022 that needs to run a method from a class that is loaded as a .dll file in the current instance of VS while debugging. I want to do something like this:
We don't really care what we are debugging as long as we have access to a library loaded as a .dll file.
Let's say that library contains a class like this one:
class MyDebuggedProgram
{
public static void MyMethod()
{
Console.WriteLine("Hello World");
}
}
And in the source code of my Visual Studio extension I want to be able to call that code like this:
class MyExampleExtensionClass
{
public void onBtnClick()
{
var resultOfCallingLibraryMethod = SomeMethodThatCallsMyMethod();
}
}
I want to have access to all the classes, their methods and properties that are loaded in the current program that we are debugging.
Is there an easy way to do this?
I am attempting to write a C# source generator that throws a warning/error under certain conditions using GeneratorExecutionContext.ReportDiagnostic. My source generator is able to run and output errors successfully upon building a sample project in Visual Studio. However, my errors do not show up as green/red squiggles in the Visual Studio editor. This is supposed to be possible with Roslyn analyzers, according to Microsoft's documentation, but nothing is said of source generators specifically. Since source generators are treated like Roslyn analyzers, though, I imagine this should be possible. I've managed to replicate my issue with a small example, consisting of a source generator project and a test project on which to run the generator. As a test, the generator reports a diagnostic error whenever it sees a method that doesn't return void. I intend for red squiggles to appear under the offending method's name:
Source generator:
[Generator]
public class SampleGenerator : ISourceGenerator
{
public void Execute(GeneratorExecutionContext context)
{
DataReceiver r = (DataReceiver)context.SyntaxReceiver;
foreach(MethodDeclarationSyntax method in r.Methods)
{
IMethodSymbol symbol = (IMethodSymbol)context.Compilation.GetSemanticModel(method.SyntaxTree).GetDeclaredSymbol(method);
if(symbol.ReturnType.SpecialType != SpecialType.System_Void)
{
context.ReportDiagnostic(Diagnostic.Create(
new DiagnosticDescriptor(
"SG0001",
"Non-void method return type",
"Method {0} returns {1}. All methods must return void.",
"yeet",
DiagnosticSeverity.Error,
true), symbol.Locations.FirstOrDefault(), symbol.Name, symbol.ReturnType.Name));
}
}
context.AddSource("yert", "namespace test { public class testclass { } }");
}
public void Initialize(GeneratorInitializationContext context)
{
context.RegisterForSyntaxNotifications(() => new DataReceiver());
}
}
public class DataReceiver : ISyntaxReceiver
{
public List<MethodDeclarationSyntax> Methods { get; } = new List<MethodDeclarationSyntax>();
public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
{
if(syntaxNode is MethodDeclarationSyntax synt)
{
Methods.Add(synt);
}
}
}
Example code:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
static string ok() => "hello";
}
When I compile the example code with the generator, Visual Studio tells me that the build has errors, and correctly reports the custom diagnostic in the error list. I can click on the custom error, and my cursor moves to the offending method in the editor. However, no red squiggles appear. I know that my source generator is being run by Intellisense, because I am able to see the custom test namespace and class my generator defines.
Does Visual Studio support code underlining for diagnostics reported by C# source generators? If so, what is wrong with the above code? Thanks in advance.
I solved this by separating out the code analysis logic into its own class and adding an analyzer and source generator into the same assembly, with the analysis logic only doing code emmission in the source generator. The analysis logic runs in different contexts, each context having a different reportdiagnostic, so it accepted an Action to report diagnostic.
There are a lot of questions floating around with this problem and i've worked through them ll with no joy.
I am receiving this error:
Method 'get_UserImageCDNUrl' in type 'App.Web.WebConfig' from assembly
'App.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does
not have an implementation.
Which is really strange because I am trying to run Api.Web which has no reference to App.Web, the only thing they have in common are references to other projects (Models.Domain and Models.DTO).
I have an interface:
IResourceCompiler in an assembly "Models.Domain"
I have an abstract class which implements this interface in the same assembly (Models.Domain) called WebConfigBase
In the "App.Web" and "Api.Web" projects they each have a class called WebConfig which inherit from WebConfigBase, therefore both WebConfig classes in App and Api are implementations of IResourceCompiler.
I tried to add a property
string UserImageCDNUrl {get;}
to IResourceCompiler and added the property to WebConfigBase
public string UserImageCDNUrl
{
get { return ""; }
}
so the property would be accessible to both Api and Web projects through their own WebConfig classes, and i get the exception above.
I have looked for hours to try and see why this happens with no joy.
I've cleared my Obj folders, cleaned, rebuilt, checked for any instances in GAC (there aren't any) and i'm still stuck on this.
Everything works fine until i try to add a new property to the interface (and base class)
OK, so bizarrely adding a reference to App.Web in Api.Web and removing it again has solved the issue.
I have no idea why, but it did.
I changed the version of App.Web to 1.0.0.1 and the error was still showing 1.0.0.0, which is what prompted me to do it.
I wish there was a more reasonable explanation but there isn't. Such an infuriating issue i'm just glad to be done with it.
Best of luck to anyone else who experiences this, my thought's are with you
For the records, in my case this was caused by two projects referencing different versions of the same package. At least fixing this solved the issue.
There can be many reasons for this, all the previous answers represent a case of this problem.
What I suggest doing is:
while your program is running open Resource Monitor -> CPU tab and in the search handles input box, search for the assembly that supposedly doesn't implement that method.
In the search results you'll see the path of your assembly, and most likely the path that you see isn't the one that you expect. Delete the assembly from this unexpected path so that the correct assembly gets loaded.
In many cases I become this error.
It seems like Cached assembly and I found them in UserProfile.
My solution is:
Save solution and close Visual Studio
Delete entire folder "c:\Users(user)\AppData\Local\Microsoft\VisualStudio\14.0\ProjectAssemblies\"
Start Visual Studio
Work...
Hope it helps.
I just remove the reference of current project (which is showing error) , and add again to other project in which project this was referenced build and it start working fine.
hope this help someone.
try this
public interface IResourceCompiler
{
string UserImageCDNUrl {get;}
}
public abstract class WebConfigBase : IResourceCompiler
{
public abstract string UserImageCDNUrl {get;}
}
public class WebConfig : WebConfigBase
{
public override string UserImageCDNUrl { return "whatever you want";}
}
or that way too:
public interface IResourceCompiler
{
string UserImageCDNUrl {get;}
}
public abstract class WebConfigBase : IResourceCompiler
{
public virtual string UserImageCDNUrl {get { return string.empty;}}
}
public class WebConfig : WebConfigBase
{
public override string UserImageCDNUrl { return "whatever you want";} // or return base.UserImageCDNUrl ;
}
I was seeing this problem in Visual Studio 2017.
Upgrading to visual studio 2019 solved the problem for me.
I'm trying to reproduce the C# compiler error CS0840 with the exact code that's given in the website:
class Test36
{
public int myProp { get; } // CS0840
// to create a read-only property
// try the following line instead
public int myProp2 { get; private set; }
}
public Form1()
{
InitializeComponent();
Test36 test = new Test36();
}
I'm running it on .NET 4.0 using Visual Studio Community 2015. Surprisingly, I cannot reproduce it. Compiler doesn't throw any error:
Why the compiler isn't throwing any error?
You're using Visual Studio 2015, which implements C# 6. The fact that you're targeting .NET 4 is irrelevant - most of the C# 6 language features don't depend on framework features at all. The C# 6 code you're using can easily be compiled without reference to any modern CLR or framework features - it could have worked with .NET 1.0 if the language designers had decided to :)
You'll need to set you language level to C# 5 to see an error here. Do that in the project properties / Build / Advanced dialog:
You'll then get this error:
error CS8026: Feature 'readonly automatically implemented properties' is not available in C# 5. Please use language version 6 or greater.
Admittedly that's not the error you actually wanted to see - I think you'll need to use an earlier version of the compiler to get that exact error.
I guess it is because you are on Visual Studio 2015 with C# 6 which allows you to specify properties that are only set from the constructor (aka read-only properties).
See the following example:
class Test
{
public Test() // <-- this one does compile since it is the constructor
{
MyProp = 1;
}
public void SomeMethod() // <-- this one doesn't compile
{
MyProp = 1;
}
public int MyProp { get; } // <-- no CS0840 any more!
}
The main.cs of my project returns the following warning:
Warning 1 The type 'Extensions.MessageDetails' in 'PATH\Extensions.cs' conflicts with the imported type 'Extensions.MessageDetails' in 'path\lib.dll'. Using the type defined in 'path\Extensions.cs'. path\main.cs
What is wrong with my project? How to get rid of the warning?
The code of my project has the following structure:
Extensions.cs
namespace Extensions
{
public class MessageDetails
{
public string message { get; set; }
public string link { get; set; }
public string picture { get; set; }
public string name { get; set; }
public string caption { get; set; }
public string description { get; set; }
public string userid { get; set; }
public string username { get; set; }
public object actions { get; set; }
public object privacy { get; set; }
public object targeting { get; set; }
}
}
lib.dll
namespace MyClassLib {
public class MyClassLibFoo {
public void foo(MessageDetails parameters) {
/* .. */
}
}
}
main.cs
using MyClassLib;
using Extensions;
class Program
{
static void Main(string[] args)
{
MessageDetails md = new MessageDetails();
}
}
In my case, with Visual Studio 2013, I found that one of my class libraries had developed a reference to itself. I think it happened when I added a new project to my solution or it was a bug, but either way it was causing this exact issue.
Check your project references for any circular references.
It seems like Extensions.cs is both part of the project that builds lib.dll and your main.exe
Remove it from one of the project to fix this issue.
I had this kind of issue where I had reverted from a target .NET Framework version of 4.5.2 to 4.0.
Classes in my App_Code folder had methods that called methods in other classes in that folder. When I created a standard folder I named "AppCode", and moved my classes into it, I no longer had the issue.
If I re-created the "App_Code" folder and move my classes back into it, I will have this issue again. I'm convinced it has to do with my .NET Framework version or that Visual Studio just doesn't deal well with changing it after being initially built/targeted to another version.
You can't have two copies of the extensions class, even though the code is the same they are not seen as the same object. Both your dll and main application will need to reference the exact same one.
You could try creating a 'Common Files' class library and add the extensions class to it, that way you will always be using the correct class
I had this problem with a project that is also hosted on NuGet. I checked all project references. Finally, the object browser revealed that the DLL of an older version of my NuGet package was somehow loaded in Visual Studio from the NuGet cache folder ("C:\Users\{username}\.nuget\packages"). I removed the package from the cache folder, it disappeared from the object browser and everything was working fine again.
I had a Shared Project, "Project A," which was included in both "Project B" and "Project C."
"Project A" was added as a Shared Project in "Project B" and "Project C."
"Project A" also included a traditional reference to "Project B."
To correct the problem, I removed the reference to "Project B" from "Project A."
If you really need to have both classes declared or referenced in two separate dll, you can mark your class as internal.
Internal types or members are accessible only within files in the same assembly, therefore it will prevent the collision.
After reading through many answers on SO the solution was still unclear. My situation was similar but the solution was found by:
Example project Name: My.Example.Project
Opening my project
Open the References dropdown
Finding My.Example.Project in the References section
Deleting the reference to My.Example.Project
That fixed it!
I had faced same problem. Just a simple solution for that.
Check your project references there must be same project reference. just remove that, it will work.
sometimes I get this error - it's a bug though in my case.. All I have to do to fix it is change the first letter of my script file name from upper case to lowercase in the file in Explorer /
(or in Unity Engine in my case)
and then change the name / class accordingly in my script. Idk why this happens.. just does - and Idk why this fix works .. but in my case it always does. - Otherwise you probably have 2 copies of the same script / same class name for 2 diff scripts. Hope this helps.
I fixed this error by deleting the .suo file in the directory sturcture vs directory. stop vs then delete restart vs. that worked for me.