{"id":1642,"date":"2025-01-21T18:13:24","date_gmt":"2025-01-21T18:13:24","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/01\/21\/winforms-analyze-this-me-in-visual-basic\/"},"modified":"2025-01-21T18:13:24","modified_gmt":"2025-01-21T18:13:24","slug":"winforms-analyze-this-me-in-visual-basic","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/01\/21\/winforms-analyze-this-me-in-visual-basic\/","title":{"rendered":"WinForms: Analyze This (Me in Visual Basic)"},"content":{"rendered":"

If you\u2019ve never seen the movie Analyze This<\/em>, here\u2019s the quick pitch: A member
\nof, let\u2019s say, a New York family clan with questionable habits decides to
\nseriously considers therapy to improve his mental state. With Billy Crystal and
\nRobert De Niro driving the plot, hilarity is guaranteed. And while Analyze
\nThis!<\/em> satirically tackles issues of a caricatured MOB world, getting to the
\nroot of problems with the right analytical tools is crucial everywhere. All the
\nmore in a mission critical LOB-App world.<\/p>\n

Enter the new WinForms Roslyn Analyzers<\/strong>, your domain-specific \u201ccounselor\u201d
\nfor WinForms applications. With .NET 9, we\u2019re rolling out these analyzers to
\nhelp your code tackle its potential issues\u2014whether it\u2019s
\nbuggy behavior, questionable patterns, or opportunities for improvement.<\/p>\n

What Exactly is a Roslyn Analyzer?<\/h2>\n

Roslyn analyzers are a core part of the Roslyn compiler platform, seamlessly
\nworking in the background to analyze your code as you write it. Chances are,
\nyou\u2019ve been using them for years without even realizing it. Many features in
\nVisual Studio, like code fixes, refactoring suggestions, and error diagnostics,
\nrely on or even just are<\/em> Analyzers or CodeFixes to enhance your development
\nprocess. They\u2019ve become such an integral part of modern development that we
\noften take them for granted as just \u201chow things work\u201d.<\/p>\n\n

The coolest thing: This Roslyn based compiler platform is not a black box.
\nThey provide an extremely rich API, and not only Microsoft\u2019s Visual Studio IDE
\nor Compiler teams can create Analyzers. Everyone can. And that\u2019s why WinForms
\npicked up on this technology to improve the WinForms coding experience.<\/p>\n

It\u2019s Just the Beginning \u2014 More to Come<\/h2>\n

With .NET 9 we\u2019ve laid the foundational infrastructure for WinForms-specific
\nanalyzers<\/strong> and introduced the first set of rules. These analyzers are designed
\nto address key areas like security, stability, and productivity. And while this
\nis just the start, we\u2019re committed to expanding their scope in future releases,
\nwith more rules and features on the horizon.<\/p>\n

So, let\u2019s take a real look of what we got with the first sets of Analyzers we\u2019re
\nintroducing for .NET 9:<\/p>\n

Guidance for picking correct InvokeAsync Overloads<\/h2>\n

With .NET 9 we have introduced a series of new Async APIs for WinForms. This
\nblog
\npost<\/a>
\ndescribes the new WinForms Async feature in detail. This is one of the first
\nareas where we felt that WinForms Analyzers can help a lot in preventing issues
\nwith your Async code.<\/p>\n

One challenge when working with the new Control.InvokeAsync API is selecting
\nthe correct overload from the following options:<\/p>\n

public async Task InvokeAsync(Action callback, CancellationToken cancellationToken = default)
\npublic async Task<T> InvokeAsync<T>(Func<T> callback, CancellationToken cancellationToken = default)
\npublic async Task InvokeAsync(Func<CancellationToken, ValueTask> callback, CancellationToken cancellationToken = default)
\npublic async Task<T> InvokeAsync<T>(Func<CancellationToken, ValueTask<T>> callback, CancellationToken cancellationToken = default)<\/p>\n

Each overload supports different combinations of synchronous and asynchronous
\nmethods, with or without return values. The linked blog post provides
\ncomprehensive background information on these APIs.<\/p>\n

Selecting the wrong overload however can lead to unstable code paths in your
\napplication. To mitigate this, we\u2019ve implemented an analyzer to help developers
\nchoose the most appropriate InvokeAsync overload for their specific use cases.<\/p>\n

Here\u2019s the potential issue: InvokeAsync can asynchronously invoke both
\nsynchronous and asynchronous methods. For asynchronous methods, you might pass a
\nFunc<Task>, and expect it to be awaited, but it will not. Func<T> is
\nexclusively for asynchronously invoking a synchronous called method \u2013 of which
\nFunc<Task> is just an unfortunate special case.<\/p>\n

So, in other words, the problem arises because InvokeAsync can accept any<\/em>
\nFunc<T>. But only Func<CancellationToken, ValueTask> is properly awaited by
\nthe API. If you pass a Func<Task> without the correct signature\u2014one that
\ndoesn\u2019t take a CancellationToken and return a ValueTask\u2014it won\u2019t be awaited.
\nThis leads to a \u201cfire-and-forget\u201d scenario, where exceptions within the function
\nare not handled correctly. If such a function then later throws an exception, it
\nwill may corrupt data or go so far as to even crash your entire application.<\/p>\n

Take a look at the following scenario:<\/p>\n

private async void StartButtonClick(object sender, EventArgs e)
\n{
\n _btnStartStopWatch.Text = _btnStartStopWatch.Text != “Stop” ? “Stop” : “Start”;<\/p>\n

await Task.Run(async () =>
\n {
\n while (true)
\n {
\n await this.InvokeAsync(UpdateUiAsync);
\n }
\n });<\/p>\n

\/\/ ****
\n \/\/ The actual UI update method
\n \/\/ ****
\n async Task UpdateUiAsync()
\n {
\n _lblStopWatch.Text = $”{DateTime.Now:HH:mm:ss – fff}”;
\n await Task.Delay(20);
\n }
\n}<\/p>\n

This is a typical scenario, where the overload of InvokeAsync which is supposed
\nto just return something other<\/em> than a task is accidentally used. But the
\nAnalyzer is pointing that out:<\/p>\n\n

So, being notified by this, it also becomes clear that we actually need to
\nintroduce a cancellation token so we can gracefully end the running task, either
\nwhen the user clicks the button again or \u2013 which is more important \u2013 when the
\nForm actually gets closed. Otherwise, the Task would continue to run while the
\nForm gets disposed. And that would lead to a crash:<\/p>\n

private async void ButtonClick(object sender, EventArgs e)
\n {
\n if (_stopWatchToken.CanBeCanceled)
\n {
\n _btnStartStopWatch.Text = “Start”;
\n _stopWatchTokenSource.Cancel();
\n _stopWatchTokenSource.Dispose();
\n _stopWatchTokenSource = new CancellationTokenSource();
\n _stopWatchToken = CancellationToken.None;<\/p>\n

return;
\n }<\/p>\n

_stopWatchToken = _stopWatchTokenSource.Token;
\n _btnStartStopWatch.Text = “Stop”;<\/p>\n

await Task.Run(async () =>
\n {
\n while (true)
\n {
\n try
\n {
\n await this.InvokeAsync(UpdateUiAsync, _stopWatchToken);
\n }
\n catch (TaskCanceledException)
\n {
\n break;
\n }
\n }
\n });<\/p>\n

\/\/ ****
\n \/\/ The actual UI update method
\n \/\/ ****
\n async ValueTask UpdateUiAsync(CancellationToken cancellation)
\n {
\n _lblStopWatch.Text = $”{DateTime.Now:HH:mm:ss – fff}”;
\n await Task.Delay(20, cancellation);
\n }
\n }<\/p>\n

protected override void OnFormClosing(FormClosingEventArgs e)
\n {
\n base.OnFormClosing(e);
\n _stopWatchTokenSource.Cancel();
\n }<\/p>\n

The analyzer addresses this by detecting incompatible usages of InvokeAsync and
\nguiding you to select the correct overload. This ensures stable, predictable
\nbehavior and proper exception handling in your asynchronous code.<\/p>\n

Preventing Leaks of Design-Time Business Data<\/h2>\n

When developing custom controls or business control logic classes derived from
\nUserControl, it\u2019s common to manage its behavior and appearance using
\nproperties. However, a common issue arises when these properties are
\ninadvertently set at design time. This typically happens because there is no
\nmechanism in place to guard against such conditions during the design phase.<\/p>\n\n

If these properties are not properly configured to control their code serialization behavior, sensitive data set during design time may unintentionally leak into the generated code. Such leaks can result in:<\/p>\n

Sensitive data being exposed in source code, potentially published on platforms like GitHub.
\nDesign-time data being embedded into resource files, either because necessary
\nTypeConverters for the property type in question are missing, or when the form
\nis localized.<\/p>\n

Both scenarios pose significant risks to the integrity and security of your
\napplication.<\/p>\n

Additionally, we aim to avoid resource serialization whenever possible. With
\n.NET 9, the Binary Formatter and related APIs have been phased
\nout<\/a>
\ndue to security and maintainability concerns. This makes it even more critical
\nto carefully control what data gets serialized and how.<\/p>\n

The Binary Formatter was historically used to serialize objects, but it had
\nnumerous security vulnerabilities that made it unsuitable for modern
\napplications. In .NET 9, we eliminated this serializer entirely to reduce attack
\nsurfaces and improve the reliability of applications. Any reliance on resource
\nserialization has the potential to reintroduce these risks, so it is essential to adopt safer
\npractices.<\/p>\n

To help you, the developer, address this issue, we\u2019ve introduced a
\nWinForms-specific analyzer. This analyzer activates when all the following
\nmechanisms to control the CodeDOM serialization process for properties are
\nmissing:<\/p>\n

SerializationVisibilityAttribute<\/strong>: This attribute controls how (or if)
\nthe CodeDOM serializers should serialize the content of a property.
\nThe property is not read-only<\/strong>, as the CodeDOM serializer ignores
\nread-only properties by default.
\nDefaultValueAttribute<\/strong>: This attribute defines the default value of a
\nproperty. If applied, the CodeDOM serializer only serializes the property
\nwhen the current value at design time differs from the default value.
\nA corresponding private bool ShouldSerialize<PropertyName>() method<\/strong> is
\nnot implemented. This method is called at design (serialization) time to
\ndetermine whether the property\u2019s content should be serialized.<\/p>\n

By ensuring at least one of these mechanisms is in place, you can avoid
\nunexpected serialization behavior and ensure that your properties are handled
\ncorrectly during the design-time CodeDOM serialization process.<\/p>\n

But\u2026this Analyzer broke my whole Solution!<\/h2>\n

So let\u2019s say you\u2019ve developed a domain-specific UserControl, like in the
\nscreenshot above, in .NET 8. And now, you\u2019re retargeting your project to .NET 9.
\nWell, obviously, at that moment, the analyzer kicks in, and you might see
\nsomething like this:<\/p>\n\n

In contrast to the previously discussed Async Analyzer, this one has a Roslyn
\nCodeFix attached to it. If you want to address the issue by instructing the
\nCodeDOM serializer to unconditionally never<\/strong> serialize the property content,
\nyou can use the CodeFix to make the necessary changes:<\/p>\n\n

As you can see, you can even have them fixed in one go throughout the whole
\ndocument. In most cases, this is already the right thing to do: the analyzer
\nadds the SerializationVisibilityAttribute on top of each flagged property,
\nensuring it won\u2019t be serialized unintentionally, which is exactly what we want:<\/p>\n

.
\n .
\n .
\n [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
\n public string NameText
\n {
\n get => textBoxName.Text;
\n set => textBoxName.Text = value;
\n }<\/p>\n

[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
\n public string EmailText
\n {
\n get => textBoxEmail.Text;
\n set => textBoxEmail.Text = value;
\n }<\/p>\n

[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
\n public string PhoneText
\n {
\n get => textBoxPhone.Text;
\n set => textBoxPhone.Text = value;
\n }
\n .
\n .
\n .<\/p>\n

Copilot to the rescue!<\/h3>\n

There is an even more efficient way to handle necessary edit-amendments for
\nproperty attributes. The question you might want to ask yourself is: if there
\nare no attributes applied at all to control certain aspects of the property,
\ndoes it make sense to not only ensure proper serialization guidance but also to
\napply other design-time attributes?<\/p>\n

But then again, would the effort required be even greater\u2014or would it?<\/p>\n

Well, what if we utilize Copilot to amend all<\/em> relevant property attributes
\nthat are really useful at design-time, like the DescriptionAttribute or the
\nCategoryAttribute? Let\u2019s give it a try, like this:<\/p>\n\n

Depending on the language model you picked for Copilot, you should see a result
\nwhere we not only resolve the issues the analyzer pointed out, but Copilot also
\ntakes care of adding the remaining attributes that make sense in the context.<\/p>\n

Copilot shows you the code it wants to add, and you can merge the suggested
\nchanges with just one mouse click.<\/p>\n\n

And those kind of issues are surely not the only area where Copilot can assist
\nyou bigtime in the effort to modernize your existing WinForms applications.<\/p>\n

But if the analyzer flagged hundreds of issues throughout your entire solution,
\ndon\u2019t panic! There are more options to configure the severity of an analyzer at
\nthe code file, project, or even solution level:<\/p>\n

Suppressing Analyzers Based on Scope<\/h3>\n

Firstly, you have the option to suppress the analyzer(s) on different scopes:<\/p>\n

In Source:<\/strong> This option inserts a #pragma warning disable directive
\ndirectly in the source file around the flagged code. This approach is useful
\nfor localized, one-off suppressions where the analyzer warning is unnecessary
\nor irrelevant. For example:<\/p>\n

#pragma warning disable WFO1000
\npublic string SomeProperty { get; set; }
\n#pragma warning restore WFO1000<\/p>\n

In Suppression File:<\/strong> This adds the suppression to a file named
\nGlobalSuppressions.cs<\/em> in your project. Suppressions in this file are scoped
\nglobally to the assembly or namespace, making it a good choice for
\nlarger-scale suppressions. For example:<\/p>\n

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(
\n “WinForms.Analyzers”,
\n “WFO1000”,
\n Justification = “This property is intentionally serialized.”)]<\/p>\n

In Source via Attribute:<\/strong> This applies a suppression attribute directly to
\na specific code element, such as a class or property. It\u2019s a good option when
\nyou want the suppression to remain part of the source code documentation. For
\nexample:<\/p>\n

[System.Diagnostics.CodeAnalysis.SuppressMessage(
\n “WinForms.Analyzers”,
\n “WFO1000”,
\n Justification = “This property is handled manually.”)]
\npublic string SomeProperty { get; set; }<\/p>\n

Configuring Analyzer Severity in .editorconfig<\/h3>\n

To configure analyzer severity centrally for your project or solution, you can
\nuse an .editorconfig<\/em> file. This file allows you to define rules for specific
\nanalyzers, including their severity levels, such as none, suggestion, warning,
\nor error. For example, to change the severity of the WFO1000 analyzer:<\/p>\n

# Configure the severity for the WFO1000 analyzer
\ndotnet_diagnostic.WFO1000.severity = warning<\/p>\n

Using .editorconfig Files for Directory-Specific Settings<\/h3>\n

One of the powerful features of .editorconfig files is their ability to control
\nsettings for different parts of a solution. By placing .editorconfig<\/em> files in
\ndifferent directories within the solution, you can apply settings only to
\nspecific projects, folders, or files. The configuration applies hierarchically,
\nmeaning that settings in a child directory\u2019s .editorconfig file can override
\nthose in parent directories.<\/p>\n

For example:<\/p>\n

Root-level .editorconfig:<\/strong> Place a general .editorconfig file at the
\nsolution root to define default settings that apply to the entire solution.
\nProject-specific .editorconfig:<\/strong> Place another .editorconfig file in the
\ndirectory of a specific project to apply different rules for that project while
\ninheriting settings from the root.
\nFolder-specific .editorconfig:<\/strong> If certain folders (e.g., test projects,
\nlegacy code) require unique settings, you can add an .editorconfig file to those
\nfolders to override the inherited configuration.<\/p>\n

\/solution-root
\n \u251c\u2500\u2500 .editorconfig (applies to all projects)
\n \u251c\u2500\u2500 ProjectA\/
\n \u2502 \u251c\u2500\u2500 .editorconfig (overrides root settings for ProjectA)
\n \u2502 \u2514\u2500\u2500 CodeFile.cs
\n \u251c\u2500\u2500 ProjectB\/
\n \u2502 \u251c\u2500\u2500 .editorconfig (specific to ProjectB)
\n \u2502 \u2514\u2500\u2500 CodeFile.cs
\n \u251c\u2500\u2500 Shared\/
\n \u2502 \u251c\u2500\u2500 .editorconfig (applies to shared utilities)
\n \u2502 \u2514\u2500\u2500 Utility.cs<\/p>\n

In this layout, the .editorconfig<\/em> at the root applies general settings to all
\nfiles in the solution. The .editorconfig<\/em> inside ProjectA<\/em> applies additional or
\noverriding rules specific to ProjectA<\/em>. Similarly, ProjectB<\/em> and Shared
\ndirectories<\/em> can define their unique settings.<\/p>\n

Use Cases for Directory-Specific .editorconfig Files Test Projects:<\/strong>
\nDisable or lower the severity of certain analyzers for test projects, where some
\nrules may not be applicable.<\/p>\n

# In TestProject\/.editorconfig
\ndotnet_diagnostic.WFO1000.severity = none
\nLegacy Code: Suppress analyzers entirely or reduce their impact for legacy codebases to avoid unnecessary noise.
\n# In LegacyCode\/.editorconfig
\ndotnet_diagnostic.WFO1000.severity = suggestion
\nExperimental Features: Use more lenient settings for projects under active development while enforcing stricter rules for production-ready code.<\/p>\n

By strategically placing .editorconfig files, you gain fine-grained control over
\nthe behavior of analyzers and coding conventions, making it easier to manage
\nlarge solutions with diverse requirements. Remember, the goal of this analyzer
\nis to guide you toward more secure and maintainable code, but it\u2019s up to you to
\ndecide the best pace and priority for addressing these issues in your project.<\/p>\n

As you can see: An .editorconfig<\/em> file or a thoughtfully put set of such files
\nprovides a centralized and consistent way to manage analyzer behavior across
\nyour project or team.<\/p>\n

For more details, refer to the .editorconfig
\ndocumentation<\/a>.<\/p>\n

So, I have good ideas for WinForms Analyzers \u2013 can I contribute?<\/h2>\n

Absolutely! The WinForms team and the community are always looking for ideas to
\nimprove the developer experience. If you have suggestions for new analyzers or
\nenhancements to existing ones, here\u2019s how you can contribute:<\/p>\n

Open an issue<\/strong>: Head over to the WinForms GitHub
\nrepository<\/a> and open an issue describing
\nyour idea. Be as detailed as possible, explaining the problem your analyzer
\nwould solve and how it could work.
\nJoin discussions<\/strong>: Engage with the WinForms community on GitHub or other
\nforums. Feedback from other developers can help refine your idea.
\nContribute code<\/strong>: If you\u2019re familiar with the .NET Roslyn analyzer
\nframework, consider implementing your idea and submitting a pull request to
\nthe repository. The team actively reviews and merges community contributions.
\nTest and iterate<\/strong>: Before submitting your pull request, thoroughly test
\nyour analyzer with real-world scenarios to ensure it works as intended and
\ndoesn\u2019t introduce false positives.<\/p>\n

Contributing to the ecosystem not only helps others but also deepens your
\nunderstanding of WinForms development and the .NET platform.<\/p>\n

Final Words<\/h2>\n

Analyzers are powerful tools that help developers write better, more reliable,
\nand secure code. While they can initially seem intrusive\u2014especially when they
\nflag many issues\u2014they serve as a safety net, guiding you to avoid common
\npitfalls and adopt best practices.<\/p>\n

The new WinForms-specific analyzers are part of our ongoing effort to modernize
\nand secure the platform while maintaining its simplicity and ease of use.
\nWhether you\u2019re working on legacy applications or building new ones, these tools
\naim to make your development experience smoother.<\/p>\n

If you encounter issues or have ideas for improvement, we\u2019d love to hear from
\nyou! WinForms has thrived for decades because of its passionate and dedicated
\ncommunity, and your contributions ensure it continues to evolve and remain
\nrelevant in today\u2019s development landscape.<\/p>\n

Happy coding!<\/p>\n

The post WinForms: Analyze This (Me in Visual Basic)<\/a> appeared first on .NET Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

If you\u2019ve never seen the movie Analyze This, here\u2019s the quick pitch: A member of, let\u2019s say, a New York […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[],"class_list":["post-1642","post","type-post","status-publish","format-standard","hentry","category-dotnet"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1642","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1642"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1642\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1642"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1642"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1642"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}