### Motivation and Context
Resolves#3887
Before:
```csharp
var result = await kernel.InvokeAsync(excuseFunction, new("I missed the F1 final race"));
```
After:
```csharp
var result = await kernel.InvokeAsync(excuseFunction, new() { ["input"] = "I missed the F1 final race" });
```
- Replaces WithServices/WithPlugins callback-based methods with
Services/Plugins properties. It makes it less fluent, but it brings it
into line with the current best-practices patterns used by ASP.NET, it
reduces nesting, it avoids confusion about when the callbacks are
invoked, it avoids async-related issues, and it makes the pre-Build
syntax for adding plugins to the builder much closer to the post-Build
syntax for adding plugins to the Kernel.
- Plugins added as services are now automatically resolved as part of
Kernel construction. The Kernel will prefer to use a collection it's
explicitly handed, but if it isn't given one, it'll try to fetch a
collection from the services, and if it can't find that, it'll try to
fetch all IKernelPlugins from the services.
- Renamed With methods to Add methods to improve parity both with
current ASP.NET practices as well as between when doing `builder.AddXx`
and `builder.Services.AddXx`.
- Renamed `AddPluginFromObject<T>` to `AddFromType<T>`.
- Remove `new()` constraint from `AddFromType<T>` and instead use
ActivatorUtilities.CreateInstance. The KernelBuilder.Plugins property
contains the same IServiceCollection as the builder, and so
`AddFromType<T>` has access to it and can use it with CreateInstance to
resolve any plugin object ctor arguments from the service provider. For
example, HttpPlugin has a ctor that takes an HttpClient, so now doing
`builder.Plugins.AddFromType<HttpPlugin>()` will find an HttpClient in
the container and use it automatically when the plugins are built as
part of Build.
- Removed WithLoggerFactory and WithCulture. The latter is basically
never used, and it's much more like the Data property and event handlers
on the Kernel, where it can easily be mutated on the Kernel instance and
doesn't need any builder support. WithLoggerFactory was used a lot, but
mainly because of the patterns employed in the tests, and it's easily
replacable with AddLogging.
- Added IKernelBuilder interface. It's implemented by KernelBuilder and
returned from a new AddKernel extension method on IServiceCollection,
adding a singleton KernelPluginCollection and a transient Kernel to the
container. IKernelBuilder has both the Services and Plugins properties,
and also has Build, but Build throws an exception if it's used on the
instance returned from AddKernel, per feedback that it can lead to folks
accidentally building the container multiple times.
- Changed all of the extensions on KernelBuilder to instead by on
IKernelBuilder.
@davidfowl, @halter73, please ensure this is in line with your feedback.
Thanks!
---------
Co-authored-by: Mark Wallace <[email protected]>
Co-authored-by: SergeyMenshykh <[email protected]>
### Motivation and Context
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
### Description
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [ ] The code builds clean without any errors or warnings
- [ ] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [ ] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
### Motivation and Context
- `Kernel.RunAsync` will only support running a single function
- Plans can be use dto run multiple functions if needed or
- Developers can create their own strategy to do this
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
### Motivation and Context
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
This PR contains changes to fix SK syntax examples after
`KernelResult`/`FunctionResult` functionality was merged.
### Description
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
1. Fixed result output in SK syntax examples.
2. Updated XML documentation.
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
### Motivation and Context
As part of the Skill -> Plugin rename the `ImportSkill` and
`ImportSemanticSkillFromDirectory` where renamed to use the term
`Plugin`. These methods actually import functions to the Kernel so this
PR renames them to match what they actually do.
We want to reserve `ImportPlugin` for use later when we add more plugin
support to the SK.
So now we do this:
`var functions = kernel.ImportFunctionsFromDirectory(...);`
In future we will do this
`var plugin = kernel.ImportPluginFromDirectory(...);`
The plugin instance will contain a list of functions in addition to
other data about the plugin.
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [ ] The code builds clean without any errors or warnings
- [ ] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [ ] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
### Motivation and Context
Rename Skills to Functions for SK core and abstractions packages. Third
sub task from https://github.com/microsoft/semantic-kernel/issues/2119.
### Description
- Remove the `Microsoft.SemanticKernel.SkillDefinition` namespace and
promote classes previously contained to `Microsoft.SemanticKernel`, this
is to reduce the number of `using`s that client code required.
- Rename variable/function names using skillName to pluginName.
- Rename skill collection interfaces/classes to use function collection.
- Leave some obsolete methods/properties to help with the upgrade from
earlier releases.
### Contribution Checklist
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
### Description
Throughout the repo, we have a mix of `logger` and `log` (plus
variations such as `Log`, `_log`) used to hold an `ILogger` instance.
This PR seeks to standardize the name `logger`, `Logger` and `_logger`
to represent ILogger object references -- including properties and
method parameters -- and `Log` as the method (action) that the logger
can take.
**To reviewers**, this is a large and extraordinarily mundane PR with
many identical substitutions. Please take a closer look at:
- IKernel.cs
- Kernel.cs
- SKContext.cs
...as these additionally contain Obsoleted properties.
### Contribution Checklist
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
=> This is a breaking change.
"KernelSyntaxExamples" is the only outstanding project under /samples
that still uses project references to access the kernel libraries.
This change consolidates all the building, linked dotnet SDK code in
SK-dotnet.sln into a single top-level folder. This will simplify build
jobs, automatic code owner assignment, and other dev ops tasks.
Coming next: other projects in samples will get removed from the
dotnet/SK-dotnet.sln solution, and a new solution with dedicated builds
created for the /samples folder.
TBD:
- Language-specific code "samples" will move into a similar subfolder
for each language.
- The current "/samples" folder (at the root) will likely become
something like "apps", with the demo apps promoted to the top-level
folder for better discoverability.
- notebooks may also move to this folder in the future.
Co-authored-by: name <email>
Roger Barreto