I'd like to create a solution that controls the project references in C# projects. Ideally, this solution is IDE-agnostic so that it can be used with Visual Studio, Jetbrains Rider, or even VS Code. The reason for this is that I've seen solutions that are completely messed up due to people creating almost arbitrary project references. It's super hard to get them straight after a project has grown to a certain size.
I know that Visual Studio Enterprise offers this out-of-the-box. Unfortunately, in my current company we do not have VS Enterprise. Thus, I want to create that on my own.
So what would be the best way to do it? After doing some research I think leveraging the .NET Compiler Platform ("Roslyn") with its Workspace API might be a good idea? Seems like I could deploy it as a NuGet package which can then be used in any IDE or build-automation. But maybe there's an easier or better way, I'd like to hear your opinion on that before I start digging into it.
Also: if the "Roslyn"-way is the right one is there some good resources on how to create an analyzer that works with the Workspace APIs?
Thanks in advance.
In your analyser, register a compilation start action:
public override void Initialize(AnalysisContext context)
{
context.RegisterCompilationStartAction(Initialize);
}
private void Initialize(CompilationStartAnalysisContext context)
{
var compilation = context.Compilation;
}
From that compilation object, you have various options:
var referencedAssemblyNames = compilation.ReferencedAssemblyNames;
or
var references = compilation.References;
Then do your analysis. To report diagnostics, register an action on the CompilationStartAnalysisContext using context.RegisterCompilationEndAction.
If you don't need to look at actual project content for your analysis, you can simply use RegisterCompilationAction as follows:
[DiagnosticAnalyzer(LanguageNames.CSharp)]
public sealed class TooManyReferencesAnalyzer : DiagnosticAnalyzer
{
private static DiagnosticDescriptor TooManyReferences { get; } =
new DiagnosticDescriptor(
"DEMO",
"Don't use too many references",
"The project '{0}' has {1} references",
category: "Maintainability",
defaultSeverity: DiagnosticSeverity.Warning,
isEnabledByDefault: true);
public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics =>
ImmutableArray.Create(TooManyReferences);
public override void Initialize(AnalysisContext context)
{
context.RegisterCompilationAction(AnalyzeCompilation);
}
private void AnalyzeCompilation(CompilationAnalysisContext context)
{
var compilation = context.Compilation;
int referenceCount = compilation.References.Count();
if (referenceCount > 5)
{
context.ReportDiagnostic(
Diagnostic.Create(
TooManyReferences,
null,
compilation.AssemblyName,
referenceCount));
}
}
}
Related
For context, I'm building an application that needs to download/unpack packages and their dependencies from arbitrary package sources (including the public gallery by default) and upgrade those packages to the latest version when requested. There are no project.json files or similar, it's all code driven. It's not a particularly complicated use case and didn't require too much code in the v2 APIs.
In v3 however, I can't figure out how to correctly interact with the local package store. For example, the FolderNuGetProject class that I would have thought lists all the packages on disk at a given location in FolderNuGetProject.GetInstalledPackagesAsync() just returns an empty enumerable. To make matters more confusing, FolderNuGetProject.PackageExists() actually does return whether the package exists on disk, which means GetInstalledPackagesAsync() and PackageExists() appear to be inconsistent.
None of the other NuGetProject derivatives appear related to the file system. Is there some other way of listing the packages that have been installed into a particular folder? If I need to create my own NuGetProject (and I'm hoping I don't), are there any methods that will help with parsing NuGet-generated folder names into package IDs and versions, or is the only reliable way of getting the ID and version to open the nuspec (and are there any easy to find methods for that)?
One interpretation of why this isn't working as I expect is that NuGetProject.GetInstalledPackagesAsync() isn't actually intended to get the installed packages (I.e., those that have been downloaded and unpacked), but rather those that have been declared in whatever project system is in use. For example, the BuildIntegratedNuGetProject class appears to return package references for the packages in the project.json, regardless of their status on disk. That would also explain why FolderNuGetProject just returns an empty enumerable, because there are no "declared" packages if you're just looking at the local repository.
TL;DR: What is the best way to crawl the local package store and get the packages and versions that are present there?
(this was also issue #2664 on the NuGet GitHub project, but was moved here by request)
Introduction
I have the same question and I looked your post on GitHub, Google and here. I try a lot of things to find the local packages.
I found some solutions, but I don't know if it's the best way to do it.
I posted a question about local packages too, because I can list all local packages, but I can't have the AssemblyReferences property (dll).
Code example
var rootPath = #"pathWhereNuGetPackagesAre";
var logger = new Logger();
List<Lazy<INuGetResourceProvider>> providers = new List<Lazy<INuGetResourceProvider>>();
providers.AddRange(Repository.Provider.GetCoreV3());
FindLocalPackagesResourceV2 findLocalPackagev2 = new FindLocalPackagesResourceV2(rootPath);
var packageFound = findLocalPackagev2.GetPackages(logger, CancellationToken.None).FirstOrDefault();
//found, but missing a lot of informations...
var supportedFramework = new[] { ".NETFramework,Version=v4.6" };
var searchFilter = new SearchFilter(true)
{
SupportedFrameworks = supportedFramework,
IncludeDelisted = false
};
// The trick here is to put the local nuget path, not using the URL : https://api.nuget.org/v3/index.json
PackageSource localSource = new PackageSource(rootPath);
SourceRepository localRepository = new SourceRepository(localSource, providers);
PackageSearchResource searchLocalResource = await localRepository
.GetResourceAsync<PackageSearchResource>();
var packageFound3 = await searchLocalResource
.SearchAsync("Newtonsoft.Json", searchFilter, 0, 10, logger, CancellationToken.None);
var thePackage = packageFound3.FirstOrDefault();
// found but missing the assemblies property
public class Logger : ILogger
{
private List<string> logs = new List<string>();
public void LogDebug(string data)
{
logs.Add(data);
}
public void LogVerbose(string data)
{
logs.Add(data);
}
public void LogInformation(string data)
{
logs.Add(data);
}
public void LogMinimal(string data)
{
logs.Add(data);
}
public void LogWarning(string data)
{
logs.Add(data);
}
public void LogError(string data)
{
logs.Add(data);
}
public void LogInformationSummary(string data)
{
logs.Add(data);
}
public void LogErrorSummary(string data)
{
logs.Add(data);
}
}
Hope this will help!
In Visual Studio, Open package manager console.
List local (installed) packages use following command.
Get-Package
You can list all available packages on feed with following command
Get-Package -ListAvailable
If this commands are not working, check "Packege Manager Settings"->"Package Source" and confirm nuget feed configured correctly. (If you dont see your feed URL, You should add your feed there.) for details: Consume nuget package from VS
You can also check nuget feed configuration from this file
C:\Users{{user}}\AppData\Roaming\NuGet\NuGet.config
for more details about nuget config file: nuget config file
Also, Local nuget packages should ve stored at this path
C:\Users{{user}}.nuget\packages
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.
I'm trying to create simple extension for Visual Studio for Mac which will handle the moment when user saves the document (sample project is on GitHub, right here).
Here's how looks my implementation of ICommandHandler<SaveCommandArgs>:
[Export(typeof(ICommandHandler))]
[Name(nameof(SaveCommandHandler))]
[ContentType(StandardContentTypeNames.Code)]
[TextViewRole(PredefinedTextViewRoles.PrimaryDocument)]
public class SaveCommandHandler : ICommandHandler<SaveCommandArgs>
{
public string DisplayName => nameof(SaveCommandHandler);
private readonly IEditorCommandHandlerServiceFactory _editorCommandHandlerServiceFactory;
[ImportingConstructor]
public SaveCommandHandler(IEditorCommandHandlerServiceFactory editorCommandHandlerServiceFactory)
{
_editorCommandHandlerServiceFactory = editorCommandHandlerServiceFactory;
}
public bool ExecuteCommand(SaveCommandArgs args, CommandExecutionContext executionContext)
{
try
{
var service = _editorCommandHandlerServiceFactory.GetService(args.TextView);
Debug.WriteLine($"I am executing something on save with {service.GetType()}");
}
catch (Exception ex)
{
Debug.WriteLine(ex);
}
return true;
}
public CommandState GetCommandState(SaveCommandArgs args)
{
return CommandState.Available;
}
}
Good point: system call the constructor of this handler, when you start editing the first file
Bad point: ExecuteCommand method never called, as well as GetCommandState method
Any ideas why it doesn't work?
I was trying to do all the things according to the documentation on official wiki in github project for visual studio api
Unfortunately, there're only samples for quick info and autocomplete features. No samples for ICommandHandler-s, haven't found any similar projects for Visual Studio for Mac as well
I agree the examples since Microsoft Visual Studio SDK documentation is horrible with no good examples of ICommandHandler.
I tried your exact code in visual studio 2022 on Windows 10 and the ExecuteCommand function is called.
So your code is fine.
I think the core problem here is that the ICommandHandler interface structure is somewhat newer and Microsoft did a poor job of properly checking for custom command handlers and adding calls.
I am trying to do a similar thing where I add an ICommandHandler to intercept the GoToDefinition command using an ICommandHandler, using this very similar code I can't get the ExecuteCommand function to fire ever.
I have been able to intercept commands using Microsofts older, yuckier DTE or DTE2 interface.
//provider constructor code
var dte2 = (DTE2)Package.GetGlobalService(typeof(DTE));
dte2.Events.CommandEvents.BeforeExecute += CommandEvents_BeforeExecute;
private static void CommandEvents_BeforeExecute(string guid, int id, object customIn, object customOut, ref bool cancelDefault)
{ //All events fired here use, the guid you want is likely
// Microsoft.VisualStudio.VSConstants.CMDSETID.StandardCommandSet97_string
// With an ID defined in
// Microsoft.VisualStudio.VSConstants.VSStd97CmdID
Debug.WriteLine("CommandEvents_BeforeExecute1 " + String.Format(
"dte2 GUID: {0}\nID: {1}\nIn: {2}\nOut: {3}",
guid, id, customIn, customOut));
}
I'm currently refactoring a medium size application due to some terminology changes in the business terms. We have around 121 SpecFlow feature files that would need to be changed.
I like how you can "deprecate" an API in C#, first as warnings:
[Obsolete("Use MyClass.NewMethod instead")]
public void OldMethod() { }
Then compiler errors:
[Obsolete("Use MyClass.NewMethod instead", true)]
public void OldMethod() { }
It would be nice to have this sort of functionality for SpecFlow steps:
[When("I old foo", Obsolete = true)]
[When("I new foo")]
public void WhenIFoo() { }
Is there any way to mark steps in SpecFlow as obsolete so other developers know the steps need to be changed in their Feature files, but not prevent them from authoring and running tests? And as an added bonus, Is there a way to optionally cause compiler or test run failures?
Starting with version v2.4, SpecFlow respects [Obsolete] attributes on step bindings.
For your example you would probably use it like this:
[When("I old foo")]
[Obsolete("you should use WhenIFoo instead")]
public void WhenIOldFoo() { }
[When("I new foo")]
public void WhenIFoo() { }
As the default behavior for using such steps a warning is issued. Utilizing the obsoleteBehavior attribute on SpecFlow's <runtime> configuration, you can change that, esp. failing test execution:
<specFlow>
...
<runtime obsoleteBehavior="Error" />
</specFlow>
In the meantime the Wiki-page for the Configuration has been updated to document that feature.
I still haven't found a solution directly in SpecFlow, but I did Get It To Work⢠using an extension method to the ScenarioContext:
Note: This uses MsTest, but I'm sure other unit testing frameworks have a way of marking tests as "pending" or inconclusive with a message.
using TechTalk.SpecFlow;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace MyTestProject
{
public static class ScenarioContextExtensions
{
public static void MarkStepObsolete(this ScenarioContext scenario, string newStep, params object[] newStepFormatArgs)
{
var message = string.Format(#"This step is obsolete. Use '" + scenario.CurrentScenarioBlock + " " + newStep + "' instead.", newStepFormatArgs);
Assert.Inconclusive(message);
}
}
}
Now in your step definitions you make the old steps "obsolete" and they show up as inconclusive tests which give you a hint to a replacement step:
[When(#"I click the ""(.*)"" anchor")]
public void WhenIClickTheAnchor(string anchorText)
{
ScenarioContext.Current.MarkStepObsolete(#"I click the ""{0}"" link", anchorText);
}
[When(#"I click the ""(.*)"" link")]
public void WhenIClickTheLink(string linkText)
{
// ...
}
And it shows up in the Test Explorer panel:
Assert.Inconclusive Failed - This step is obsolete. Use 'When I click the "Home" link' instead.
This at least tells other developers how to fix the new tests they were writing while I was changing the terminology in the existing scenarios.
There is a way to to do it with steps Scopes:
[When("I old foo", Scope(Tag = "Obsolete"))]
[When("I new foo")]
public void WhenIFoo() { }
Ensure the tag(its a regex) is unique because the idea is to not match any of the scenarios tagged.
What will happen is that your test will be marked as Not Run and more importantly the scenarios using this step will get a pink step so it will be visible compile time.
If you want to mark as obsolete the whole class then just simply tag the class as follows:
[Binding, Scope(Tag = "Obsolete")]
public class Steps
Reference:
https://github.com/techtalk/SpecFlow/wiki/Scoped-bindings#scoping-tips--tricks
this question follows my previous question.
I have a c# ASP.NET application and i want to provide support for plugins. Plugins can be custom c# classes, javascript, html, css, images, etc.
I see no problem as long as my application is extended with c# classes because all the user has to do is create a new "class library" project in visual studio and implement the interfaces, i provide. Then build a dll out of it and upload it to my server. The plugin-developer can add static files (html, js, css, etc.) into this project as well but i found some problems with that:
Every static file i add to the plugin project gets the build action "content" and it seems i cannot read those files from my server. (see my previously answered question). I have to manually select "Embedded Resource" on each file, so it is packed with the plugin dll.
I want to support Typescript for the plugins. The Typescript compiler generates javascript files in the same directory as the typescript-files. But the javascript files are not included in the project and therefore i have to include these in the plugin project and then set the correct build action. I don't want the plugin developers to do that all the time.
If the static files have the build action "enbedded resources", then the server can pickup these files by using the assembly.GetManifestResourceNames() method. This method returns the resources as a string. The path is not separated by \ or / but with a dot instead. So i am not able to distinguish between file path (this is relevant) or filename (also relevant to pickup the correct files), because the original filename can also have dots.
So i am starting to question the "class library" project type is right for my needs. Is there a way to get around of my issues or do i have to use another project type?
Thank you for any help!
Edit: Changed the question a little bit so it is better to understand.
You could make a zip package with the plugin dll and files. NuGet also uses this mechanism. A .nupkg is also just a zip file.
I would start by looking at MEF (Managed Extensibility Framework).
MSDN information can be found here: https://msdn.microsoft.com/en-us/library/dd460648(v=vs.110).aspx
From that link you can get more information and I believe there is a tutorial as well.
Oh, for me it seems very simple.
Let the developer create the plugin freestyle and put all the additional files in a directory, let's call it extras
To implement the your interface they will need your assembly so I guess you will ship it via nuget, or just some link. No matter what the case, provide them with some powershell script what will be required to run before the final build
The script would create zip archive from the extras directory and add it to the ClassLibrary project as EmbeddedResource.
As you mentioned earlier, you can access EmbeddedResource. So all you would do is to unpack it and you would have the exact directory tree.
The best idea would be to provide project template with script included, and also the empty zip archive added as embedded resource (it will be easier to just pack the files in the script and replace the file), and pre-build action set to run the script.
Am I missing something?
What about this.
In your web application, you could add a function that loop into your plugin directory and find DLL implementing an Iplugin (name is up to you) interface.
The interface is defined in a class library that both your web application and plugins have to implement.
You can use the Httpcontext Server mappath to read javascript and other files.
Here is a very basic implementation
First, you have the plugin interface (a class library implemented both by the web application and the individual plugins) I implemented sample properties and methods...
using System.Web;
public interface IPlugin
{
string Name { get; set; }
string Output { get; set; }
void Load(ref httpcontext Context);
void Dispose();
void Display();
}
Next, you have the Actual plugin class library we want to implement.
using System.Web;
using IPlugins;
public class AwesomePlugin : IPlugins.IPlugin
{
private string _Name = "AwesomePlugin";
private HttpContext _Context;
public string Name {
get { return _Name; }
set { _Name = value; }
}
public string Output {
get { return "Yay !!!"; }
set {
throw new NotImplementedException();
}
}
public void Display()
{
throw new NotImplementedException();
}
public void Dispose()
{
throw new NotImplementedException();
}
public void Load(ref Web.HttpContext Context)
{
}
}
Finally, you dynamically load your plugins so you can use them in your application.
private Dictionary<string, IPlugins.IPlugin> _Plugins = new Dictionary<string, IPlugins.IPlugin>();
public void LoadPlugins()
{
lock (static_LoadPlugins_IpluginType_Init) {
try {
if (InitStaticVariableHelper(static_LoadPlugins_IpluginType_Init)) {
static_LoadPlugins_IpluginType = typeof(IPlugins.IPlugin);
}
} finally {
static_LoadPlugins_IpluginType_Init.State = 1;
}
}
string ServerPath = HttpContext.Current.Server.MapPath("~") + "Plugins";
dynamic Plugins = io.Directory.GetFiles(ServerPath);
foreach (string PluginPath in Plugins) {
dynamic Assembly = system.Reflection.Assembly.LoadFile(PluginPath);
Type PluginClass = Assembly.GetTypes.Where(T => T.GetInterface("IPlugin") != null).First;
IPlugins.IPlugin MyPlugin = Activator.CreateInstance(PluginClass);
MyPlugin.Load(httpcontext.Current);
_Plugins.#add(PluginClass.ToString, MyPlugin);
}
}
static bool InitStaticVariableHelper(Microsoft.VisualBasic.CompilerServices.StaticLocalInitFlag flag)
{
if (flag.State == 0) {
flag.State = 2;
return true;
} else if (flag.State == 2) {
throw new Microsoft.VisualBasic.CompilerServices.IncompleteInitialization();
} else {
return false;
}
}
That way, you can implement whatever you want in your plugin.
I believe you could load your plugins in a separate appdomain with restricted permissions to everything.
The files (Javascript / CSS / Html) should be available by accessing the full path of the file.
string ServerPath = HttpContext.Current.Server.MapPath("~") + "Plugins";
If the resources is embedded into the plugin DLL, you could read the stream from the loaded assembly or let the plugin manage its own embedded files.
For question Number 2, you can use
MS Build
to change the contenttype during build process.
You have to make yourself confident with MS Build