text:
Multiple inheritance in the native component is ignored with RnWinRT.

A native component I'm trying to reuse for React Native migration has multiple inheritance. A simplified code is like the following.
public interface INative1
{
    void method1();
}
public interface INative2: public INative1
{
    void method2();
}
public class Native: public INative2 {}

With this setup, only method2() is projected to JavaScript, and method1() is unavailable. The following code is not traversing up the inheritance chain but only looking through the direct parents. ☹
react-native-winrt-main\rnwinrt\rnwinrt\react\strings\base.cpp

projected_object_instance::projected_object_instance(const winrt::IInspectable& instance) : m_instance(instance)
{
    auto iids = winrt::get_interfaces(m_instance); <<<< Getting direct parents.
    for (auto&& iid : iids)
    {
        if (auto iface = find_interface(iid))
        {
            m_interfaces.push_back(iface); <<<< Not pushing back the ancestors of the direct parent interface.
        }
    }
}

For a quick reference on behavior and functionality, interfaces have two important functions in WinRT that are relevant here: QueryInterface and GetIids. QueryInterface is how you get a pointer to a particular interface that a type supports, and GetIids is how a type "advertises" which interfaces it supports. In general, these two sets of interfaces - which Interfaces/IIDs QueryInterface supports and returns success/a valid pointer back for, as well as which IIDs are included in the list returned from GetIids - should be the same (there's an exception where interfaces can support an interface, but not advertise it; these are typically referred to as "cloaked" interfaces, but this is not really relevant to this discussion). WinRT does not have proper interface inheritance. Therefore, although your idl defines INative2 as deriving from INative1, it really doesn't and instead only derives from IInspectable. Therefore, in order to call functions on the INative1 interface, consuming code would need to call QueryInterface with INative1's IID, get back a pointer to the interface, and then call the function.
RnWinRT doesn't really deal with types in this way - the developer does not indicate which interface it wishes to invoke a particular function on. Instead, it relies on the GetIids function to get a list of supported interfaces on a per-object basis. Therefore, if you are seeing that you are able to invoke functions on INative1 in non-JavaScript code (i.e. the code calls QueryInterface, which succeeds), but are unable to invoke the same functions on the same objects using RnWinRT (i.e. GetIids does not advertise the interface), then there's a bug in your component. The type's QueryInterface method responds to both INative1 as well as INative2, whereas its GetIids only advertises INative2.
That all said, interface requirements (which may "appear" to be like inheritance in idl definitions) do persist into the metadata (and I'm now slightly curious how Chakra handled this situation). So, in theory, we could modify each interface definition to have an additional array of required interfaces and then merge those into the m_interfaces array when constructing an object instance. I'm not a fan of that, however. This means more data, which means more binary bloat, and more runtime overhead to either de-duplicate interfaces on construction of an object interface, or to just add them all and then redundantly enumerate the same interfaces when looking for functions/properties. It seems much simpler and much more desirable for types to just behave as they are supposed to and advertise all interfaces that they support.

authors: dunhor yusuketa

repo: microsoft/react-native-winrt


text:
Adding custom headers, but not seeing them in Fiddler

Describe the bug
I'm trying to add some headers to all my routes using the code below. But when I look at my requests in Fiddler, I don't see any of my headers added to the final request.
To Reproduce
Here is the current code:
public void ConfigureServices(IServiceCollection services)
{
	// Add the reverse proxy to capability to the server
	services.AddReverseProxy()
		.LoadFromConfig(Configuration.GetSection("ReverseProxy"))
		.AddTransforms(builderContext =>
		{
			builderContext.AddPathPrefix(@"/");
			builderContext.AddRequestTransform(async transformContext =>
			{
				transformContext.ProxyRequest.Headers.Add("Authorization", "Basic <hidden-obfuscated>");
				transformContext.ProxyRequest.Headers.Add("Custom-Token", "doodah");
			});
		});

	//services.AddHttpForwarder();
	services.AddCors(options =>
		options.AddPolicy(
			"openPolicy",
			policy =>
				policy
					.AllowAnyOrigin()
					.AllowAnyMethod()
					.AllowAnyHeader()
		)
	);
}

Got Exceptions? Include both the message and the stack trace
Further technical details
YARP 1.0.0
.NET5
React front end
Windows
Here's a snapshot of what's in Fiddler after executing a request:

using the code below

Can you please share the code you are using?

I've updated the original post. I forgot to remove the comment characters...

I’ve updated the original post. I forgot to remove the comment characters around the code…
From: Miha Zupan @.>
Sent: Wednesday, December 22, 2021 08:19 AM
To: microsoft/reverse-proxy @.>
Cc: ARCHIBALD Steven @.>; Author @.>
Subject: Re: [microsoft/reverse-proxy] Adding custom headers, but not seeing them in Fiddler (Issue #1477)
EXTERNAL EMAIL :  The sender of this email is external to 3DS. Be wary of the content and do not open unexpected attachments or links. If you consider this email as spam, you can click herehttps://spam-report.3ds.com/?link=here (no login or additional action will be requested).
using the code below
Can you please share the code you are using?
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/reverse-proxy/issues/1477#issuecomment-999700427, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG47XSXTXDV3RBE6LGPLN2DUSH3AXANCNFSM5KS37BIA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.@.>>
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at @.@.>
For other languages, go to https://www.3ds.com/terms/email-disclaimer

Fiddler only shows you the requests from the client to the proxy by default, it doesn't intercept requests from the proxy to the destination without additional config.
Can you share your appsettings.json file as well, it's hard to tell which parts of this flow belong to the proxy.
What are you expecting this to do? builderContext.AddPathPrefix(@"/"); You wouldn't normally add just a slash to the request path.

Sure.
Here’s the relevant part of the appsettings.
"AllowedHosts": "*",
"ReverseProxy": {
"Routes": {
"reportServerRoute": {
"ClusterId": "reportServerCluster",
"CorsPolicy": "openPolicy",
"Match": {
"Path": "{**catch-all}"
},
}
},
"Clusters": {
"reportServerCluster": {
"Destinations": {
"reportServerDest": {
"Address": http://modsreporting-dev.mdsol.com/
}
}
}
}
I used pathprefix of “/” because the documentation for the config version implied a pathprefix was required, and I want all the routes that come into the proxy server to have these headers added. I initially tried without the pathprefix in the code version, but the results are always the same.
If you look at my screenshot, it certainly looks to me like fiddler is capturing the request from the proxy server to the final destination.
From: Chris Ross @.>
Sent: Wednesday, December 22, 2021 08:55 AM
To: microsoft/reverse-proxy @.>
Cc: ARCHIBALD Steven @.>; Author @.>
Subject: Re: [microsoft/reverse-proxy] Adding custom headers, but not seeing them in Fiddler (Issue #1477)
EXTERNAL EMAIL :  The sender of this email is external to 3DS. Be wary of the content and do not open unexpected attachments or links. If you consider this email as spam, you can click herehttps://spam-report.3ds.com/?link=here (no login or additional action will be requested).
Fiddler only shows you the requests from the client to the proxy by default, it doesn't intercept requests from the proxy to the destination without additional config.
Can you share your appsettings.json file as well, it's hard to tell which parts of this flow belong to the proxy.
What are you expecting this to do? builderContext.AddPathPrefix(@"/"); You wouldn't normally add just a slash to the request path.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/reverse-proxy/issues/1477#issuecomment-999724400, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG47XSWFG2BHEOPGKQV5ZATUSH7FHANCNFSM5KS37BIA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.@.>>
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at @.@.>
For other languages, go to https://www.3ds.com/terms/email-disclaimer

I used pathprefix of “/” because the documentation for the config version implied a pathprefix was required, and I want all the routes that come into the proxy server to have these headers added. I initially tried without the pathprefix in the code version, but the results are always the same.

Match:Path is required in the route config, AddPathPrefix does something else and is not required, remove it.
It looks like you're being redirected (302) from localhost to modsreporting-dev.mdsol.com, so that second request is bypassing the proxy entirely. Some sites do this defensively if the host header doesn't match. You can check the info level logs from the proxy to confirm. https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-6.0#configure-logging

I’m running my proxy server at localhost:44344. The proxy is supposed to forward to https://modsreporting-dev.mdsol.com.
I’m not quite sure what you mean by “host header doesn’t match”…
From: Chris Ross @.>
Sent: Wednesday, December 22, 2021 09:20 AM
To: microsoft/reverse-proxy @.>
Cc: ARCHIBALD Steven @.>; Author @.>
Subject: Re: [microsoft/reverse-proxy] Adding custom headers, but not seeing them in Fiddler (Issue #1477)
EXTERNAL EMAIL :  The sender of this email is external to 3DS. Be wary of the content and do not open unexpected attachments or links. If you consider this email as spam, you can click herehttps://spam-report.3ds.com/?link=here (no login or additional action will be requested).
I used pathprefix of “/” because the documentation for the config version implied a pathprefix was required, and I want all the routes that come into the proxy server to have these headers added. I initially tried without the pathprefix in the code version, but the results are always the same.
Match:Path is required in the route config, AddPathPrefix does something else and is not required, remove it.
It looks like you're being redirected (302) from localhost to modsreporting-dev.mdsol.com, so that second request is bypassing the proxy entirely. Some sites do this defensively if the host header doesn't match. You can check the info level logs from the proxy to confirm. https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-6.0#configure-logging
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/reverse-proxy/issues/1477#issuecomment-999741285, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG47XSWBEA6XWZZX3UGAPXLUSICDTANCNFSM5KS37BIA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.@.>>
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at @.@.>
For other languages, go to https://www.3ds.com/terms/email-disclaimer

Maybe I’m trying to set this up incorrectly.
I’m doing some development of a new React app that is a report viewing “portal” for a PowerBI Report server.
My actual report server is found at “https://modsreporting-dev.mdsol.com”.
My app is a react app that is running at “http://localhost:3000”  (Standard for a react app)
My YARP proxy server is running at “https://localhost:44344”.
I have another web api project running at “https://localhost:44300”, but I don’t need to proxy anything going to that address.
I want ALL traffic that is sent to “https://localhost:44344” to be forwarded to “https://modsreporting-dev.mdsol.com” along with the custom headers I’m trying to add.
Have I messed up something in my “ReverseProxy” section of the appsetttings.json?
From: Chris Ross @.>
Sent: Wednesday, December 22, 2021 09:20 AM
To: microsoft/reverse-proxy @.>
Cc: ARCHIBALD Steven @.>; Author @.>
Subject: Re: [microsoft/reverse-proxy] Adding custom headers, but not seeing them in Fiddler (Issue #1477)
EXTERNAL EMAIL :  The sender of this email is external to 3DS. Be wary of the content and do not open unexpected attachments or links. If you consider this email as spam, you can click herehttps://spam-report.3ds.com/?link=here (no login or additional action will be requested).
I used pathprefix of “/” because the documentation for the config version implied a pathprefix was required, and I want all the routes that come into the proxy server to have these headers added. I initially tried without the pathprefix in the code version, but the results are always the same.
Match:Path is required in the route config, AddPathPrefix does something else and is not required, remove it.
It looks like you're being redirected (302) from localhost to modsreporting-dev.mdsol.com, so that second request is bypassing the proxy entirely. Some sites do this defensively if the host header doesn't match. You can check the info level logs from the proxy to confirm. https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-6.0#configure-logging
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/reverse-proxy/issues/1477#issuecomment-999741285, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG47XSWBEA6XWZZX3UGAPXLUSICDTANCNFSM5KS37BIA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.@.>>
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at @.@.>
For other languages, go to https://www.3ds.com/terms/email-disclaimer

Your appsettings.json looks fine then. Check the logs from YARP to see what it says about those requests.

@sarchibald-mdsol - following up after the US holidays - did you resolve your issue?

Fiddler only shows you the requests from the client to the proxy by default, it doesn't intercept requests from the proxy to the destination without additional config.

@Tratcher Would you please point me to some documentation on what that additional config is?

Fiddler injects itself as an outbound client proxy. YARP disables outbound client proxy support on HttpClient by default for performance reasons, it expects to be able to directly access destinations. You'd have to turn that back on.
https://microsoft.github.io/reverse-proxy/articles/http-client-config.html#configuring-the-http-client
https://microsoft.github.io/reverse-proxy/articles/http-client-config.html#custom-iforwarderhttpclientfactory

@Tratcher, thanks.  That got pointed in the right direction.
For anyone else looking to enable Fiddler debugging with YARP, I had to add the following when configuring services:
services
    .AddReverseProxy()
    .ConfigureHttpClient((context, handler) =>
    {
        handler.UseProxy = true;
        handler.Proxy = WebRequest.DefaultWebProxy;
    });

source: gharchive/issue

authors: MihaZupan SEnglishSMP Tratcher samsp-msft sarchibald-mdsol

repo: microsoft/reverse-proxy

license: MIT

license_type: permissive

license_source: github-api


text:
CloneVerb: Fall back to partial clone

You can now try this:
$ scalar clone https://github.com/microsoft/scalar
Clone parameters:
  Repo URL:     https://github.com/microsoft/scalar
  Branch:       Default
  Cache Server: Default
  Local Cache:  C:\.scalarCache
  Destination:  C:\_git\t\scalar
  FullClone:     False
Authenticating...Succeeded
Fetching objects from remote...Succeeded
Checking out 'master'...Succeeded

$ ls scalar/src/
AuthoringTests.md  Dependencies.props     Directory.Build.targets  License.md    Protocol.md  Scalar.ruleset  SECURITY.md
CONTRIBUTING.md    Directory.Build.props  global.json              nuget.config  Readme.md    Scalar.sln      Signing.targets

$ cd scalar/src/

$ git sparse-checkout disable
remote: Enumerating objects: 418, done.
remote: Counting objects: 100% (418/418), done.
remote: Compressing objects: 100% (410/410), done.
remote: Total 483 (delta 71), reused 9 (delta 8), pack-reused 65
Receiving objects: 100% (483/483), 556.94 KiB | 8.57 MiB/s, done.
Resolving deltas: 100% (77/77), done.
Updating files: 100% (491/491), done.

$ ls
AuthoringTests.md        global.json   Scalar.Common/             Scalar.ruleset              Scalar.UnitTests/
CONTRIBUTING.md          License.md    Scalar.FunctionalTests/    Scalar.Service/             Scalar.Upgrader/
Dependencies.props       nuget.config  Scalar.Installer.Mac/      Scalar.Service.UI/          Scripts/
Directory.Build.props    Protocol.md   Scalar.Installer.Windows/  Scalar.Signing/             SECURITY.md
Directory.Build.targets  Readme.md     Scalar.MSBuild/            Scalar.sln                  Signing.targets
docs/                    Scalar/       Scalar.Notifications.Mac/  Scalar.TestInfrastructure/

or use SSH:
$ scalar clone git@github.com:microsoft/scalar.git scalar-ssh
Clone parameters:
  Repo URL:     git@github.com:microsoft/scalar.git
  Branch:       Default
  Cache Server: Default
  Local Cache:  C:\.scalarCache
  Destination:  C:\_git\t\scalar-ssh
  FullClone:     False
Fetching objects from remote...Succeeded
Checking out 'master'...Succeeded

$ cd scalar-ssh/src/

$ ls
AuthoringTests.md  Dependencies.props     Directory.Build.targets  License.md    Protocol.md  Scalar.ruleset  SECURITY.md
CONTRIBUTING.md    Directory.Build.props  global.json              nuget.config  Readme.md    Scalar.sln      Signing.targets

$ git sparse-checkout disable
remote: Enumerating objects: 418, done.
remote: Counting objects: 100% (418/418), done.
remote: Compressing objects: 100% (410/410), done.
remote: Total 483 (delta 71), reused 9 (delta 8), pack-reused 65
Receiving objects: 100% (483/483), 556.94 KiB | 9.95 MiB/s, done.
Resolving deltas: 100% (77/77), done.
Updating files: 100% (491/491), done.

$ ls
AuthoringTests.md        global.json   Scalar.Common/             Scalar.ruleset              Scalar.UnitTests/
CONTRIBUTING.md          License.md    Scalar.FunctionalTests/    Scalar.Service/             Scalar.Upgrader/
Dependencies.props       nuget.config  Scalar.Installer.Mac/      Scalar.Service.UI/          Scripts/
Directory.Build.props    Protocol.md   Scalar.Installer.Windows/  Scalar.Signing/             SECURITY.md
Directory.Build.targets  Readme.md     Scalar.MSBuild/            Scalar.sln                  Signing.targets
docs/                    Scalar/       Scalar.Notifications.Mac/  Scalar.TestInfrastructure/

We still need tests, which I will create to test these scenarios. Because GitHub turned on the partial-clone feature flag specifically for microsoft/scalar, we can verify that partial clone works correctly in terms of number of packs.

/azp run microsoft.scalar

source: gharchive/pull-request

repo: microsoft/scalar


text:
.Net: Preparation for non-string arguments support

This PR changes SK public API surface to lay the foundation for the long-awaited feature - non-string arguments. As part of this PR the following major changes were done:

The KernelArguments class is changed to support non-string arguments. Now, it's a dictionary of nullable objects rather than strings.
The KernelFunctionFromMethod class is refactored to  a) marshal function arguments as they are, without changing their type. The existing logic of converting arguments represented as strings to target parameter types is retained for backward compatibility. Another potential use case where the string -> parameter type conversion logic might be useful is in LLM function calling, where non-string (int, long, double, etc) function arguments can be provided as strings.  b) remove support for default values provided via DefaultValueAttribute in favor of native C# mechanism of optional parameters that allows default values to be provided as - ...., string p1 = "abc". The change simplifies the class code and enables implicit type conversion (e.g., int to long, float to double) performed by runtime, which would otherwise require additional code to support.
The KernelPromptTemplate, RestApiOperationRunner, GrpcOperationRunner were modified to include an argument type check that only allows string arguments and rejects arguments of other types. These temporary safeguards will be removed when these classes are refactored to support non-string arguments.

a) marshal function arguments as they are, without changing their type. The existing logic of converting arguments represented as strings to target parameter types is retained for backward compatibility.

Aren't we going to always need this, and in fact expand it? We'll want to convert from whatever is in the arguments collection to the parameter type.

enables implicit type conversion (e.g., int to long, float to double) performed by runtime, which would otherwise require additional code to support.

Is it actually meaningfully more code? As noted above, I was expecting we'd always need marshaling code to go from argument to parameter, and we'd get that effectively for free for these default values then as well.

enables implicit type conversion (e.g., int to long, float to double) performed by runtime, which would otherwise require additional code to support.

Is it actually meaningfully more code? As noted above, I was expecting we'd always need marshaling code to go from argument to parameter, and we'd get that effectively for free for these default values then as well.

As per our offline discussion, custom marshaling of method arguments is necessary to respect the TypeConverterAttribute on complex types and support type conversions, such as Guid to string, which are not supported by the runtime out of the box. This is in addition to implicit conversions like int/float to double, and int to long, etc..

authors: SergeyMenshykh stephentoub

repo: microsoft/semantic-kernel


text:
[QUESTION] - Why did our service instance shut down?

We have have some trouble understanding why our service has stopped on the particular node at a particular time.
In general, we would like to have a better view/understanding of why our services shutdown (grafefully or not), when moving or otherwise needs to close.
I don't even have information that a service or application upgrade has started at a certain point.
Area/Component:
EventStore ?
To Reproduce
Steps to reproduce the behavior:

Go to 'Service Fabric explorer'
Click on 'Desired application and/or service'
Click on "Events" in the top bar
Select a timeframe
See the list is mostly empty

Expected behavior
Events of upgrades, instance moves, etc., and specifically reasons for why stuff happended!
Observed  behavior:
Mostly nothing to display.
We have one service, reported in EventStore as (Application level):

EventInstanceId: "8c43cbf8-adbf-4d3d-8349-1c16cf1a58e6"
Additional Properties: {
"ServiceName": "fabric:/ServiceName/Api",
"ServicePackageName": "Services.Observations.ApiPkg",
"ServicePackageActivationId": "f1931f12-61ca-4787-bddc-6a3292e5b434",
"IsExclusive": true,
"CodePackageName": "Code",
"EntryPointType": "Exe",
"ExeName": "***.exe",
"ProcessId": 624,
"HostId": "6729a06a-7e1c-4508-b83d-03479726c24a",
"ExitCode": 7147,
"UnexpectedTermination": false,
"StartTime": "2021-06-25T08:16:54Z",
"ActivityId": "bd30d72c-bd88-4697-a108-019bccc8f3d0:0",
"ExitReason": "The process/container terminated with exit code:7147. Deactivating since no replica hosted. For information about common termination errors, please visit https://aka.ms/service-fabric-termination-errors"
}
I've looked at the documentation page for the exit code 7147, which is expeted when Service Fabric closes an application and it happens within an allowed timeframe.
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-diagnostics-code-package-errors#how-can-i-tell-if-service-fabric-terminated-my-code-package
We rolled an application upgrade at that time, so that could be a reason. Why is "Application upgrade" not listed as reason in meta data?
Other applications on both dev and production clusters doesn't report much either.
Please help!
Screenshots
Service Fabric Runtime Version:
Cluster version: 8.0.521.9590
Environment:

Azure
OS: Windows 2019
Version 8.0.521.9590

Assignees: /cc @microsoft/service-fabric-triage

Typically during an upgrade, your services will restart once the upgrade domain is completed. Are you doing anything unusual in your upgrade process that would remove your services (prompting SF to stop the service and remove it)?

authors: WhitWaldo clausndk

repo: microsoft/service-fabric


text:
main program

how can i put windows terminals as mi default  terminal program, i follow a lot of tutorial but the option to change it does not appear to me

i've also install the preview version of the microsoft store and still it does not appear to me, i dont know if i need download the gitbub version

repo: microsoft/terminal


text:
Tab name on fullscreen view

Description of the new feature/enhancement
It would be nice to have a kind of popup with a tab name when you switch tabs with CTRL+TAB in fullscreen mode. Without that popup, it's not clear what tabs you are switching.

This seems like it'll be served by /dup #1502, actually.

authors: DHowett-MSFT JekRock


text:
Unify resource filenames across the repository

This unifies the rest of the projects around the resource structure laid out in WindowsTerminalUniversal. Now we'll have a single flat structure for resource files and keep the qualifiers in their filenames. It's easier to manage this way.

This also pulls our application name out into the language-free resource in CascadiaPackage: this might help with #2289.

This also pulls our application name out into the language-free resource in CascadiaPackage: this might help with #2289.

[narrator voice] it did not


text:
Escape @ symbol in @example code block

Problem
Currently, the @ breaks styling if used inside the @example+```...```
Example
/**
 * GraphQL JSON type
 *
 * @example
 * ```ts
 *  import { Field, InputType } from 'type-graphql';
 *  import API from '@brix/api';
 *
 *  @InputType()
 *  export class EExampleInput {
 *    @Field(() => String)
 *    type: string;
 *
 *    @Field(() => API.GraphQLJSON)
 *    data: Object;
 *  }
 * ```
 */

Here the @brix/api breaks, and also the decorators
Example VSCode hover preview:

Can anyone look into this issue ?

I just pasted this code sample into the TSDoc Playground and it renders correctly.

Example VSCode hover preview:

As far as I know, VS Code's syntax highlighter does not use the @microsoft/tsdoc reference parser. Thus it would need to be fixed on their end.  There's not much the TSDoc can do.
The GitHub project for VS Code is here: https://github.com/microsoft/vscode

authors: brokenmass octogonz tristanMatthias

repo: microsoft/tsdoc


text:
Factory aware of target class that resolves the factory's type.

This pull request enables factory for resolving dependencies to see which class is using the factory to resolve the dependency.
For example, when you use factory to resolve Logger class, which contains parameter name in its constructor, you can provide parent's class name to automatically name the logger.
Example of final usage:
export class Logger {
  constructor(private name: string) {}

  public info(message: string) {
    console.log(`[${this.name}] ${message}`);
  }
}

// New "target" argument in factory, which contains the constructor of parent class (or undefined, if resolved directly from container)
const loggerFactory: FactoryFunction<Logger> = (_, target) => new Logger(target ? target.name : 'Default');
container.register(Logger, { useFactory: loggerFactory });

@injectable()
export class TestClass {
  constructor(logger: Logger) {
    logger.info('test') // [TestClass] test
  }
}

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: perf2711 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Is there anything a non-committer like me can do to help get this merged?
It would help us a lot to get rid of some boilerplate code, not only as described in the logging example above, but also for injecting configuration into our classes.

@asciidisco, hang tight; I will give this another look over this week. Thanks for your patients =]

I think that passing a constructor to the method leaves room for weird abuses, so instead I think it might be better to pass metadata about the constructor instead - would that still work for your scenario? I've had Hyrum's Law on my mind a lot lately, and I'm trying to keep the surface area low.

I don't own neither the PR nor would I consider myself a domain expert in DI/IoC topics nor Typescript, so I don't know how much weight you should put on my thoughts.
Back in the day when I started as a developer in the web sphere, things like you mentioned with method leaves room for weird abuses were actually a good thing, as they made things possible that the domain owners of libraries & browser vendors couldn't forsee. Therefore I wouldn't consider it a bad thing per se, that the implementation that is presented in this PR could present more powers to the user. On the other side, I use tsyringe (and not one of the other DI libraries that are around) because of its narrowed scope & clean API.
Summed up, I'd be happy with the approach of passing just the metadata that @MeltingMosaic proposed, as it would enable the use cases I have.
I'd even go that far & say that the metadata approach would not limit the proposed functionality to be used in factory functions only. From my point of view, it would be an interesting approach to inject the metadata into constructor methods that especially "ask" for them, withiout using a factory.
I'm thinking of something like this:
import {.autoInjectable, SomeMagicMetadatInterface } from 'tsyringe'

@autoInjectable()
export class Logger {
  constructor(private { name }: SomeMagicMetadatInterface) {}

  public info(message: string) {
    console.log(`[${this.name}] ${message}`);
  }
}

@autoInjectable()
export class TestClass {
  constructor(private logger: Logger) {
    logger.info('test') // [TestClass] test
  }
}

Don't know if this is a bit far fetched, but it could potentially reduce boilerplate code a bit further.

I'm still a little torn on which approach is best for this; I can see on one hand that a metadata object is just the right amount of context that the problem needs, but on the other do see how passing the target itself could enable some pretty cool stuff in the right hands.
I'm thinking maybe for now to go the route of the metadata object, starting with what we need (the targetName). And if in the future we need more (such as targetConstructor), then we can add as needed as a non-breaking change.
With regards to your idea of allowing the metadata object be injected into a class, I'm not so sure I would want to allow this; I can see this leading to code that's written in a super tight-coupled way to the DI framework, when the whole point of DI is to promote loose-coupling.

@perf2711, are you still working on this?

@Xapphire13 sorry, no, not at the moment.

repo: microsoft/tsyringe


text:
Fix assert validation logic for intput parameters

Contributes to https://github.com/microsoft/typespec/issues/3966

API change check
API changes are not detected in this pull request.

authors: azure-sdk m-nash

repo: microsoft/typespec


text:
[New Port Request] Ghostscript

Library name: Ghostscript
Library description: An interpreter for the PostScript language and for PDF.
Source repository URL: http://git.ghostscript.com/?p=ghostpdl.git;a=summary
Project homepage (if different from the source repository): https://www.ghostscript.com/
Anything else that is useful to know when adding (such as optional features the library may have that should be included):

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

repo: microsoft/vcpkg


text:
[New port request] ArduinoJson

Library name:

ArduinoJson
croncpp

Library description:

ArduinoJson is a C++ JSON library for Arduino and IoT (Internet Of Things)
croncpp is a C++11/14/17 header-only cross-platform library for handling CRON expressions. It implements two basic operations: parsing an expression and computing the next occurence of the scheduled time

Source repository URL:

https://github.com/bblanchon/ArduinoJson
https://github.com/mariusbancila/croncpp

Project homepage (if different from the source repository):

https://arduinojson.org/

Hi @ishaantantra, vcpkg already includes croncpp, please use command ./vcpkg install croncpp to install it.
Thanks.

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

authors: JackBoosY PhoebeHui ishaantantra


text:
[libpng] Different rules to link against libpng on different platforms

Is your feature request related to a problem? Please describe.
Linking against libpng requires different cmake commands on different platforms. On Windows it's
    find_package(libpng CONFIG REQUIRED)
    target_link_libraries(main PRIVATE png)

On Linux:
    find_package(libpng CONFIG REQUIRED)
    target_link_libraries(main PRIVATE png_static)

Proposed solution
Fix libpng to export the same cmake commands to include libpng in a cross-platform project. For example, like we do with libpng-turbo:
find_package(JPEG REQUIRED)
target_link_libraries(main PRIVATE ${JPEG_LIBRARIES})
target_include_directories(main PRIVATE ${JPEG_INCLUDE_DIR})

Describe alternatives you've considered
if/else branching:
if (WIN32)
    find_package(libpng CONFIG REQUIRED)
    target_link_libraries(main PRIVATE png)
else()
    find_package(libpng CONFIG REQUIRED)
    target_link_libraries(main PRIVATE png_static)
endif()

Additional context
None

a) that is an upstream issue.
b) you could use https://cmake.org/cmake/help/latest/module/FindPNG.html instead of the config

FindPNG has a similar issue on Linux:
        find_package(PNG)
        target_link_libraries(png-test PRIVATE png)

results in
usr/bin/ld: /home/rob/src/git.vcpkg/installed/x64-linux/lib/libpng.a(png.c.o): in function `png_build_16bit_table':
png.c:(.text+0x4b50): undefined reference to `pow'

It looks like FindPNG is not aware of the fact that libpng could be built statically, and doesn't add -lm on Linux. So I still need
    if (WIN32)
        find_package(PNG)
        target_link_libraries(png-test PRIVATE png)
    else()
        find_package(PNG)
        target_link_libraries(png-test PRIVATE png m)
    endif()

Maybe it's worth patching libpng in vcpkg so it exports the same linking target ("png") on all platforms?

Maybe it's worth patching libpng in vcpkg so it exports the same linking target ("png") on all platforms?

No since upstream is in control of its exported targets and all downstream targets will depend on that naming.
If you don't like the if else block use a generator expression in the target_link_libraries instead. Just chain $<IF:condition,true_string,false_string> and $<TARGET_EXISTS:target> with the exported targets or use $<PLATFORM_ID:platform_ids> to conditionally link -lm. An alternative would be to supply an patch upstream to libpng.

OK, thanks for the clarification.

authors: Neumann-A smoked-herring


text:
Cannot find GLFW header or .lib

Describe the bug
Targets using GLFW seem to have an issue finding the headers or static libraries for GLFW. Other projects I tried didn't seem to have this issue. Intellisense/autocomplete seems to think the headers are available (they show up in the list of suggestions) but the compiler can't seem to find them. I don't know enough about portfiles to see anything wrong with glfw's.
Environment

OS: Windows 10 20H2
Compiler: MSVC 19.28.29336

To Reproduce
The most basic example project fails, just create vcpkg.json, CMakeLists.txt, and main.cpp:
vcpkg.json:
{
	"name": "glfw-example",
	"version-string": "",
	"dependencies": [
		"glfw3"
	]
}

CMakeLists.txt:
project(glfw_example)
add_executable(glfw_example main.cpp)
target_link_libraries(glfw_example glfw)

main.cpp:
#include <GLFW/glfw3.h>    // fatal error C1083: Cannot open include file: 'GLFW/glfw3.h': No such file or directory

int main(int argc, char** argv)
{
	return 0;
}

Expected behavior
The example project shown above should compile and link successfully.
Failure logs
>------ Build All started: Project: glfw_install_error, Configuration: x64-Debug (default) ------
  [1/2, 0.145s]Building CXX object CMakeFiles\glfw_example.dir\main.cpp.obj
  FAILED: CMakeFiles/glfw_example.dir/main.cpp.obj
  C:\PROGRA~2\MICROS~1\2019\COMMUN~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\cl.exe  /nologo /TP   /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /FoCMakeFiles\glfw_example.dir\main.cpp.obj /FdCMakeFiles\glfw_example.dir\ /FS -c ..\..\..\main.cpp
C:\Users\matt\Downloads\glfw_install_error\main.cpp(1): fatal error C1083: Cannot open include file: 'GLFW/glfw3.h': No such file or directory
  ninja: build stopped: subcommand failed.

Build All failed.

After manually adding target_include_directories(glfw_example SYSTEM PRIVATE "C:\\Users\\matt\\Downloads\\glfw_install_error\\out\\build\\x64-Debug (default)\\vcpkg_installed\\x64-windows\\include"):
>------ Build All started: Project: glfw_install_error, Configuration: x64-Debug (default) ------
  [1/2, 0.177s]Building CXX object CMakeFiles\glfw_example.dir\main.obj
  [2/2, 0.238s]Linking CXX executable glfw_example.exe
  FAILED: glfw_example.exe
  cmd.exe /C "cd . && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\glfw_example.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe --manifests  -- C:\PROGRA~2\MICROS~1\2019\COMMUN~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\link.exe /nologo CMakeFiles\glfw_example.dir\main.obj  /out:glfw_example.exe /implib:glfw_example.lib /pdb:glfw_example.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console  glfw.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cmd.exe /C "cd /D "C:\Users\matt\Downloads\glfw_install_error\out\build\x64-Debug (default)" && C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile -executionpolicy Bypass -file D:/vcpkg/scripts/buildsystems/msbuild/applocal.ps1 -targetBinary "C:/Users/matt/Downloads/glfw_install_error/out/build/x64-Debug (default)/glfw_example.exe" -installedDir "C:/Users/matt/Downloads/glfw_install_error/out/build/x64-Debug (default)/vcpkg_installed/x64-windows/debug/bin" -OutVariable out""
  LINK Pass 1: command "C:\PROGRA~2\MICROS~1\2019\COMMUN~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\link.exe /nologo CMakeFiles\glfw_example.dir\main.obj /out:glfw_example.exe /implib:glfw_example.lib /pdb:glfw_example.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console glfw.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\glfw_example.dir/intermediate.manifest CMakeFiles\glfw_example.dir/manifest.res" failed (exit code 1104) with the following output:
C:\Users\matt\Downloads\glfw_install_error\out\build\x64-Debug (default)\LINK : fatal error LNK1104: cannot open file 'glfw.lib'
  ninja: build stopped: subcommand failed.

Build All failed.

Additional context
It should be noted that while i see vcpkg_installed/x64-windows/include/GLFW/glfw3.h, the lib file is actually vcpkg_installed/x64-windows/lib/glfw3dll.lib (glfw3dll.lib when it is trying to link against glfw.lib)

Oops. Surprised it got that far without find_package.

Oops. Surprised it got that far without find_package.


text:
Update FAQ

As noted in this message the FAQ should be updated as they are a bit outdated.
This issue can can be used to collect all issues with it.
From my side especially why not conan is horrible outdated.

Public federation vs private federation

Related issues:

#11684

@IceflowREm, sorry I forget to reopen the old issue, and thanks for reporting this issue again!

Yeah, this is incredibly outdated; in my opinion the answer is to just nuke it. This is extremely outdated and misleading on both sides.

authors: IceflowRE PhoebeHui strega-nil-ms


text:
[New Port Request]

Library name:
casbin-cpp
Library description:
An authorization library that supports access control models like ACL, RBAC, ABAC in C/C++
Source repository URL:
https://github.com/casbin/casbin-cpp.git

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

authors: LilyWangLL shishirong


text:
[sfml] Build error on arm64-android

Package: sfml:arm64-android@2.6.1
Host Environment

Host: x64-windows
Compiler: Clang 17.0.2
vcpkg-tool version: 2024-01-11-710a3116bbd615864eef5f9010af178034cb9b44
vcpkg-scripts version: 1f619be01 2024-01-30 (5 weeks ago)

To Reproduce
vcpkg install sfml:arm64-android
Failure logs
-- Using cached SFML-SFML-2.6.1.tar.gz.
-- Cleaning sources at F:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source F:/vcpkg2024/downloads/SFML-SFML-2.6.1.tar.gz
-- Applying patch fix-dependencies.patch
-- Using source at F:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean
-- Configuring arm64-android
CMake Warning at installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_configure.cmake:318 (message):
  The following variables are not used in CMakeLists.txt:

      SFML_MISC_INSTALL_PREFIX
      SFML_WARNINGS_AS_ERRORS

  Please recheck them and remove the unnecessary options from the
  `vcpkg_cmake_configure` call.

  If these options should still be passed for whatever reason, please use the
  `MAYBE_UNUSED_VARIABLES` argument.
Call Stack (most recent call first):
  ports/sfml/portfile.cmake:17 (vcpkg_cmake_configure)
  scripts/ports.cmake:170 (include)

-- Building arm64-android-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: F:/VS2022/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin/cmake.exe --build . --config Debug --target install -- -v -j7
    Working Directory: F:/vcpkg2024/buildtrees/sfml/arm64-android-dbg
    See logs for more information:
      F:\vcpkg2024\buildtrees\sfml\install-arm64-android-dbg-out.log

Call Stack (most recent call first):
  installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
  installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
  ports/sfml/portfile.cmake:27 (vcpkg_cmake_install)
  scripts/ports.cmake:170 (include)

F:\vcpkg2024\buildtrees\sfml\install-arm64-android-dbg-out.log
Change Dir: 'F:/vcpkg2024/buildtrees/sfml/arm64-android-dbg'

Run Build Command(s): F:/vcpkg2024/downloads/tools/ninja/1.10.2-windows/ninja.exe -v -v -j7 install
[1/116] F:\Library\AndroidNDK\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android21 --sysroot=F:/Library/AndroidNDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot -DGL_GLEXT_PROTOTYPES -DSFML_OPENGL_ES -DSFML_SYSTEM_EXPORTS -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/include -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/src -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/extlibs/headers/glad/include -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -frtti -fexceptions  -fPIC   -fno-limit-debug-info    -fPIC -fvisibility=hidden  -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wcast-align -Wunused -Woverloaded-virtual -Wconversion -Wsign-conversion -Wdouble-promotion -Wformat=2 -Wno-unknown-warning-option -MD -MT src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.o -MF src\SFML\System\CMakeFiles\sfml-system.dir\Clock.cpp.o.d -o src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.o -c F:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/src/SFML/System/Clock.cpp
[2/116] F:\Library\AndroidNDK\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android21 --sysroot=F:/Library/AndroidNDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot -DGL_GLEXT_PROTOTYPES -DSFML_OPENGL_ES -DSFML_SYSTEM_EXPORTS -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/include -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/src -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/extlibs/headers/glad/include -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -frtti -fexceptions  -fPIC   -fno-limit-debug-info    -fPIC -fvisibility=hidden  -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wcast-align -Wunused -Woverloaded-virtual -Wconversion -Wsign-conversion -Wdouble-promotion -Wformat=2 -Wno-unknown-warning-option -MD -MT src/SFML/System/CMakeFiles/sfml-system.dir/Lock.cpp.o -MF src\SFML\System\CMakeFiles\sfml-system.dir\Lock.cpp.o.d -o src/SFML/System/CMakeFiles/sfml-system.dir/Lock.cpp.o -c F:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/src/SFML/System/Lock.cpp

......

[114/116] F:\Library\AndroidNDK\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android21 --sysroot=F:/Library/AndroidNDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot -DFLAC__NO_DLL -DGL_GLEXT_PROTOTYPES -DOV_EXCLUDE_STATIC_CALLBACKS -DSFML_AUDIO_EXPORTS -DSFML_OPENGL_ES -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/include -IF:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/src -isystem F:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/extlibs/headers/minimp3 -isystem F:/vcpkg2024/installed/arm64-android/include/AL -isystem F:/vcpkg2024/installed/arm64-android/include -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -frtti -fexceptions  -fPIC   -fno-limit-debug-info    -fPIC -fvisibility=hidden  -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wcast-align -Wunused -Woverloaded-virtual -Wconversion -Wsign-conversion -Wdouble-promotion -Wformat=2 -Wno-unknown-warning-option -MD -MT src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterOgg.cpp.o -MF src\SFML\Audio\CMakeFiles\sfml-audio.dir\SoundFileWriterOgg.cpp.o.d -o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterOgg.cpp.o -c F:/vcpkg2024/buildtrees/sfml/src/2.6.1-f39277683b.clean/src/SFML/Audio/SoundFileWriterOgg.cpp
[115/116] cmd.exe /C "cd . && F:\Library\AndroidNDK\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android21 --sysroot=F:/Library/AndroidNDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot -fPIC -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -frtti -fexceptions  -fPIC   -fno-limit-debug-info  -static-libstdc++ -Wl,--build-id=sha1 -Wl,--no-rosegment -Wl,--no-undefined-version -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -shared -Wl,-soname,libsfml-audio-d.so -o lib\libsfml-audio-d.so src/SFML/Audio/CMakeFiles/sfml-audio.dir/ALCheck.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/AlResource.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/AudioDevice.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/Listener.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/Music.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/Sound.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundBuffer.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundBufferRecorder.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/InputSoundFile.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/OutputSoundFile.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundRecorder.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundSource.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundStream.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileFactory.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderFlac.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderMp3.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderOgg.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderWav.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterFlac.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterOgg.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterWav.cpp.o  -landroid  -lOpenSLES  lib/libsfml-system-d.so  F:/vcpkg2024/installed/arm64-android/debug/lib/libopenal.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libvorbisenc.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libvorbisfile.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libvorbis.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libogg.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libFLAC.a  -latomic -lm && cd ."
FAILED: lib/libsfml-audio-d.so
cmd.exe /C "cd . && F:\Library\AndroidNDK\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android21 --sysroot=F:/Library/AndroidNDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot -fPIC -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -frtti -fexceptions  -fPIC   -fno-limit-debug-info  -static-libstdc++ -Wl,--build-id=sha1 -Wl,--no-rosegment -Wl,--no-undefined-version -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -shared -Wl,-soname,libsfml-audio-d.so -o lib\libsfml-audio-d.so src/SFML/Audio/CMakeFiles/sfml-audio.dir/ALCheck.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/AlResource.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/AudioDevice.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/Listener.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/Music.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/Sound.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundBuffer.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundBufferRecorder.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/InputSoundFile.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/OutputSoundFile.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundRecorder.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundSource.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundStream.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileFactory.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderFlac.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderMp3.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderOgg.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileReaderWav.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterFlac.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterOgg.cpp.o src/SFML/Audio/CMakeFiles/sfml-audio.dir/SoundFileWriterWav.cpp.o  -landroid  -lOpenSLES  lib/libsfml-system-d.so  F:/vcpkg2024/installed/arm64-android/debug/lib/libopenal.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libvorbisenc.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libvorbisfile.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libvorbis.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libogg.a  F:/vcpkg2024/installed/arm64-android/debug/lib/libFLAC.a  -latomic -lm && cd ."
ld.lld: error: undefined symbol: __android_log_print
>>> referenced by logging.cpp:87 (F:/vcpkg2024/buildtrees/openal-soft/src/1.23.1-180897dbaa.clean/core/logging.cpp:87)
>>>               logging.cpp.o:(al_print(LogLevel, __sFILE*, char const*, ...)) in archive F:/vcpkg2024/installed/arm64-android/debug/lib/libopenal.a
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

Confirmed, this issue can be reproduced locally. I will try to fix it.


text:
7zip build failure

Operating system
Win11
Compiler
MSVC
Steps to reproduce the behavior
./vcpkg install 7zip

Failure logs
D:\opensource\vcpkg>vcpkg install 7zip
Computing installation plan...
The following packages will be built and installed:
7zip:x64-windows@24.09
Detecting compiler hash for triplet x64-windows...
Compiler found: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe
A suitable version of 7zip was not found (required v24.9.0) Downloading portable 7zip 24.9.0...
Extracting 7zip...
CMake Error: Problem with archive_read_next_header():
CMake Error: Problem extracting tar: D:\opensource\vcpkg\downloads\7z2409.7z
'CMake' failed while extracting D:\opensource\vcpkg\downloads\7z2409.7z.
Additional context
Note that this is a recursive failure.
I got the same error when trying to install other packages:
C:\Users\tksha\Projects\packages>D:\opensource\vcpkg\vcpkg install
Detecting compiler hash for triplet x64-windows...
Compiler found: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe
The following packages will be built and installed:
clipper2:x64-windows@1.4.0 -- C:\Users\tksha\AppData\Local\vcpkg\registries\git-trees\5b7c4d5dff8e0b28ad089e870674d497d4be1adb
eigen3:x64-windows@3.4.0#4 -- C:\Users\tksha\AppData\Local\vcpkg\registries\git-trees\17249b310c689b0722c3ee825780a8e24c7d73a2
happly:x64-windows@2021-03-19 -- C:\Users\tksha\AppData\Local\vcpkg\registries\git-trees\30ccc0778da8b49727c6cffa0c11c6ece4ac7073
nlohmann-json:x64-windows@3.11.3#1 -- C:\Users\tksha\AppData\Local\vcpkg\registries\git-trees\324d32ddba70bc49650d1a067ddcf3d0bfc6c9b6
pugixml:x64-windows@1.14 -- C:\Users\tksha\AppData\Local\vcpkg\registries\git-trees\6e38344aea6e7529afde3895e0885ed5cb0c0542

vcpkg-cmake:x64-windows@2024-04-23 -- C:\Users\tksha\AppData\Local\vcpkg\registries\git-trees\e74aa1e8f93278a8e71372f1fa08c3df420eb840
vcpkg-cmake-config:x64-windows@2024-05-23 -- C:\Users\tksha\AppData\Local\vcpkg\registries\git-trees\97a63e4bc1a17422ffe4eff71da53b4b561a7841
Additional packages (*) will be modified to complete this operation.
A suitable version of 7zip was not found (required v24.9.0) Downloading portable 7zip 24.9.0...
Extracting 7zip...
CMake Error: Problem with archive_read_next_header():
CMake Error: Problem extracting tar: D:\opensource\vcpkg\downloads\7z2409.7z
'CMake' failed while extracting D:\opensource\vcpkg\downloads\7z2409.7z.

The problem seems to be in Cmake rather than vcpkg or 7-zip.  I extracted 7z2409.7z to a tools directory with WinRAR, after which these installs ran successfully.

The problem seems to be in Cmake rather than vcpkg or 7-zip. I extracted 7z2409.7z to a tools directory with WinRAR, after which these installs ran successfully.

Can you tell me how to proceed, thanks? My 7z2409.7z file seems to be corrupted and cannot be extracted using the 7z tool, as the format is incorrect.

I successfully installed 7z.exe to the downloads/tools/7zip-24.09-windows directory. After that, move the files from the subdirectory to this directory.

authors: tksharpless yukunyi


text:
MSVCP140.dll

Describe the bug
A clear and concise description of what the bug is.
I have been using vcpkg with Visual Studio 2019 since august 2019 (i guess).
When I ran vcpkg yesterday, I saw this message:

Environment

OS: [e.g. Windows/Linux etc...] Windows
Compiler: revision - Microsoft Visual Studio 16.3.7 - C++ build tools v142

To Reproduce
Steps to reproduce the behavior:

vcpkg
See error
Repro code when

Expected behavior
A clear and concise description of what you expected to happen.
Run vcpkg normally
Failure logs
-(please attached failure logs)
Additional context
Add any other context about the problem here.

call CMD env msvc 2019
where msvcp140.dll ?

It say that msvcp140.dll is in System32, I should probably check my path

Compiler has its own library, despite the name 140, 2019 uses its dll/msvcp140.dll

?
echo %PATH%

I fixed it.
Just called vsdevcmd.bat and worked.
Thanks for all.

authors: TerensTare Voskrese


text:
[vcpkg] Repair msbuild damage and workaround the way we integrate on VS2015.

This is a fix for a pile of issues discovered by https://github.com/microsoft/vcpkg/pull/18906

VS 2015 has a bug that the $(VcpkgInstalledDir)</VcpkgInstalledDir> dance we do to get a trailing slash is not applied correctly when VcpkgInstalledDir was edited in the same property group attempting to add the trailing slash.
We need a trailing slash on VcpkgInstalledDir at all times, but https://github.com/microsoft/vcpkg/pull/16173 damaged this by removing it from TreatAsLocalProperty. Use a separate _Z property rather than TreatAsLocalProperty. Add all such slash defenses to the top of the file just beneath, eliminating need to call Path::Combine and friends by following msbuild "directory properties have a trailing slash" convention.
Move VcpkgOSTarget and VcpkgPlatformTarget into the .targets, as they aren't intended to be overridable by users and don't appear in our selection dialog box(es).
Don't bother avoiding setting vcpkg properties when VcpkgEnabled is off; after all, VcpkgEnabled is itself a vcpkg property :). I left attempts to skip creating items since creating items can hit the disk.
Add _Z to several internal msbuild variables.
Move VcpkgApplocalDeps to the .props since it's a user setting.
Don't use $(TLogLocation) directly because it is not set when the .targets is parsed on 2015.
Fixed typo in docs "VcpkgInstalledDirectory", and document the limitation that it doesn't work in 2015.
In manifest mode, put the installed tree in a subdirectory including the triplet to make changing configurations faster.

Known limitations:

If you change vcpkg.json without changing any .cpp files, we don't rebuild the dependencies even though we should. I don't know how to fix this but it doesn't appear to be a regression.

/azp run


text:
[simdjson] Update to 1.0.2

Describe the pull request

What does your PR fix?
Bump version to 1.0.2.

Which triplets are supported/not supported? Have you updated the CI baseline?
All. Yes.

Does your PR follow the maintainer guide?
Yes.

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?
<Yes / I am still working on this PR>

If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

Thanks for the update!


text:
[directxtk, directxtk12] update ports for June 2022 releaes

There is a minor release update of DirectX Tool Kit for DX11 / DX12 for June 2022. This includes some cleanup of the CMakeLists.
This port update also includes updating the directxtk12 port to make use of directx-dxc as a tools port for DXC.EXE.

Verified locally with all supported triplets:
vcpkg install directxtk:x86-windows
vcpkg install directxtk[xaudio2-8]:x86-windows --recurse
vcpkg install directxtk[xaudio2-9]:x86-windows --recurse
vcpkg install directxtk[xaudio2redist]:x86-windows --recurse
vcpkg install directxtk[xaudio2redist]:x86-windows-static-md --recurse
vcpkg install directxtk:x86-windows-static
vcpkg install directxtk:x86-windows-static-md
vcpkg install directxtk:x64-windows
vcpkg install directxtk[xaudio2-8]:x64-windows --recurse
vcpkg install directxtk[xaudio2-9]:x64-windows --recurse
vcpkg install directxtk[xaudio2redist]:x64-windows --recurse
vcpkg install directxtk[xaudio2redist]:x64-windows-static-md --recurse
vcpkg install directxtk:x64-windows-static
vcpkg install directxtk:x64-windows-static-md
vcpkg install directxtk:arm-windows
vcpkg install directxtk:arm64-windows
vcpkg install directxtk:arm64-windows-static
vcpkg install directxtk:arm64-windows-static-md
vcpkg install directxtk:x86-uwp
vcpkg install directxtk:x64-uwp
vcpkg install directxtk:arm-uwp
vcpkg install directxtk:arm64-uwp

vcpkg install directxtk:x64-mingw-static
vcpkg install directxtk[xaudio2redist]:x64-mingw-static

vcpkg install directxtk:x86-mingw-static
vcpkg install directxtk[xaudio2redist]:x86-mingw-static

vcpkg install directxtk12[core]:x86-windows
vcpkg install directxtk12[xaudio2-9]:x86-windows --recurse
vcpkg install directxtk12[xaudio2redist]:x86-windows --recurse
vcpkg install directxtk12[xaudio2redist]:x86-windows-static-md --recurse
vcpkg install directxtk12:x86-windows-static
vcpkg install directxtk12:x86-windows-static-md
vcpkg install directxtk12[core]:x64-windows
vcpkg install directxtk12[xaudio2-9]:x64-windows --recurse
vcpkg install directxtk12[xaudio2redist]:x64-windows --recurse
vcpkg install directxtk12[xaudio2redist]:x64-windows-static-md --recurse
vcpkg install directxtk12:x64-windows-static
vcpkg install directxtk12:x64-windows-static-md
vcpkg install directxtk12:arm-windows
vcpkg install directxtk12:arm64-windows
vcpkg install directxtk12:arm64-windows-static
vcpkg install directxtk12:arm64-windows-static-md
vcpkg install directxtk12:x86-uwp
vcpkg install directxtk12:x64-uwp
vcpkg install directxtk12:arm-uwp
vcpkg install directxtk12:arm64-uwp

vcpkg install directxtk12:x64-mingw-static
vcpkg install directxtk12[xaudio2redist]:x64-mingw-static

vcpkg install directxtk12:x86-mingw-static
install directxtk12[xaudio2redist]:x86-mingw-static


text:
Update vcpkg-tool to 2023-02-16.

https://github.com/microsoft/vcpkg-tool/releases/tag/2023-02-16

You probably also have to merge https://github.com/microsoft/vcpkg-tool/pull/906 to get a green ci.

The new CI regressions are expected, due to unblocking of port builds by no longer pulling in unsupported features via unsupported features and ports. This is the work which started with #28619, lead to https://github.com/microsoft/vcpkg-tool/pull/846, but was ignored in the course of merging https://github.com/microsoft/vcpkg-tool/pull/856 which unblocked even more ports.
As a quick mitigation, I suggest to compare with the CI build before this PR, and then add expected failures to the CI baseline.

Verified this update resolves all the issues with the new xbox supports term.

Saving this screenshot demonstrating why I changed vtk:

Similarly, what changed for nghttp2:

REGRESSION: blend2d:x64-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add blend2d:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: blend2d:x86-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add blend2d:x86-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/877, fixed by ca1cb8a3540f45a5b95dfa040e01c3922eae33f6
REGRESSION: boost-random:arm-uwp failed with BUILD_FAILED. If expected, add boost-random:arm-uwp=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: boost-random:x64-uwp failed with BUILD_FAILED. If expected, add boost-random:x64-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/856, fixed by 99c4b28ed3bd8f6b3ca76de135a62dd978fd4fe3
Note also that the whole boost ecosystem got port-version bumped because https://github.com/microsoft/vcpkg/pull/29540 and https://github.com/microsoft/vcpkg/pull/29481 forgot to rerun generate-ports.ps1.
REGRESSION: clipper2:arm-uwp failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:arm-uwp=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: clipper2:arm64-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:arm64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: clipper2:x64-linux failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:x64-linux=fail to /agent/_work/1/s/scripts/azure-pipelines/../ci.baseline.txt.
REGRESSION: clipper2:x64-uwp failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:x64-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: clipper2:x64-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: clipper2:x64-windows-static failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:x64-windows-static=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: clipper2:x64-windows-static-md failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:x64-windows-static-md=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: clipper2:x86-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add clipper2:x86-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:arm-uwp failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:arm-uwp=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:arm64-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:arm64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:x64-linux failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:x64-linux=fail to /agent/_work/1/s/scripts/azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:x64-uwp failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:x64-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:x64-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:x64-windows-static failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:x64-windows-static=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:x64-windows-static-md failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:x64-windows-static-md=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jxrlib:x86-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add jxrlib:x86-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/877, fixed by 88775f549a891afaebadf5c5b711a954effa6c9f
REGRESSION: vcpkg-gfortran:x64-uwp failed with POST_BUILD_CHECKS_FAILED. If expected, add vcpkg-gfortran:x64-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: vcpkg-gfortran:x64-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add vcpkg-gfortran:x64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: vcpkg-gfortran:x64-windows-static failed with POST_BUILD_CHECKS_FAILED. If expected, add vcpkg-gfortran:x64-windows-static=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: vcpkg-gfortran:x64-windows-static-md failed with POST_BUILD_CHECKS_FAILED. If expected, add vcpkg-gfortran:x64-windows-static-md=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: vcpkg-gfortran:x86-windows failed with POST_BUILD_CHECKS_FAILED. If expected, add vcpkg-gfortran:x86-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/834, fixed by be95ce72b161093f9f3d2847c2792229fbf991a3
REGRESSION: monkeys-audio:x86-windows failed with BUILD_FAILED. If expected, add monkeys-audio:x86-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Error is fatal error C1090: PDB API call failed, error code '23', a sign that mspdbsrv failed. This is one of the many reasons we dislike /Zi. 64bd5dad0e94c5fffb85b81fe79c574c790ca761 patches that out.
REGRESSION: harfbuzz:arm-uwp failed with BUILD_FAILED. If expected, add harfbuzz:arm-uwp=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: harfbuzz:x64-uwp failed with BUILD_FAILED. If expected, add harfbuzz:x64-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/856 , previously this was a cascaded failure. Upstream has:
// in buildtrees\harfbuzz\src\6.0.0-21fda9578f.clean\src\hb-ft.h
#if defined(WINAPI_FAMILY) && (WINAPI_FAMILY != WINAPI_FAMILY_DESKTOP_APP)
#define generic GenericFromFreeTypeLibrary
#endif

resulting in
../src/6.0.0-21fda9578f.clean/src/hb-ft.cc(985): error C2039: 'generic': is not a member of 'FT_FaceRec_'
C:\Dev\vcpkg\installed\x64-uwp\include\freetype/freetype.h(1077): note: see declaration of 'FT_FaceRec_'
../src/6.0.0-21fda9578f.clean/src/hb-ft.cc(1010): error C2039: 'generic': is not a member of 'FT_FaceRec_'
C:\Dev\vcpkg\installed\x64-uwp\include\freetype/freetype.h(1077): note: see declaration of 'FT_FaceRec_'

so this problem is an upstream issue with not supporting non-desktop Windows. Marked as unsupported in 04e8c539e848d19ae3d70b7a0445a9b031625be3
REGRESSION: nghttp2:arm-uwp failed with BUILD_FAILED. If expected, add nghttp2:arm-uwp=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: nghttp2:x64-uwp failed with BUILD_FAILED. If expected, add nghttp2:x64-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.

Probably broken by https://github.com/microsoft/vcpkg-tool/pull/856, this port is full of "optional detection" stuff which disabled features before because it happened to install early, but now it happened to install much later. There are significant differences in what it reports between the "working" and "broken" states; I'm not sure how to fix this one yet.
# REGRESSION: functions-framework-cpp:arm-uwp failed with BUILD_FAILED. If expected, add functions-framework-cpp:arm-uwp=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/856, needs VerifyVersionInfo not present on UWP. See also https://github.com/GoogleCloudPlatform/functions-framework-cpp/issues/207. Fixed by 45223aeca00e157af010498a32f962f1949ac37d
# REGRESSION: openimageio:arm64-windows failed with BUILD_FAILED. If expected, add openimageio:arm64-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/856, simd.h missing msvc-arm64 support, Fixed by cherry picking upstream change https://github.com/OpenImageIO/oiio/commit/1aa2cf6edf9f2bd57a21998fceeb095cbe1f2b84 in 4fa6f5c5d279c26590c0cfc2da1c2b1332690b94
REGRESSION: openmesh:x64-linux failed with POST_BUILD_CHECKS_FAILED. If expected, add openmesh:x64-linux=fail to /agent/_work/1/s/scripts/azure-pipelines/../ci.baseline.txt.

Broken by https://github.com/microsoft/vcpkg-tool/pull/877, fixed by 71df8be5d5389b36b8ab6a6fa081fbc4088ad66f
REGRESSION: vtk:x86-windows failed with BUILD_FAILED. If expected, add vtk:x86-windows=fail to C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt.

Probably broken by https://github.com/microsoft/vcpkg-tool/pull/856 changing the installation order and letting pegtl install before vtk, exposing port bugs in vtk. See screenshot in previous comment. Fixed by forcing vtk to use pegtl-2 by adding that to the path used by the include statement in 6b9ac36fcbcad8b2194277508ff2338b57055369
Drive by 9cd208792c4577353b044e1b542c65be8f9518dc , I didn't realize qt5-x11extras was in ci.baseline.txt already :)
REGRESSION: cmake-user:x64-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: cmake-user:x64-windows-static cascaded, but it is required to pass. (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: cmake-user:x64-windows-static-md cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: cmake-user:x86-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-mathgl:x64-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-mathgl:x64-windows-static cascaded, but it is required to pass. (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-mathgl:x64-windows-static-md cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-mathgl:x86-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-opencv:x64-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-opencv:x64-windows-static cascaded, but it is required to pass. (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-opencv:x64-windows-static-md cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-opencv:x86-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-openimageio:x64-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-openimageio:x64-windows-static cascaded, but it is required to pass. (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-openimageio:x64-windows-static-md cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-openimageio:x86-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
REGRESSION: vcpkg-ci-paraview:x86-windows cascaded, but it is required to pass. (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).

Pending.

Probably broken by https://github.com/microsoft/vcpkg-tool/pull/856 changing the installation order and letting pegtl install before vtk, exposing port bugs in vtk. See screenshot in previous comment. Fixed by forcing vtk to use pegtl-2 by adding that to the path used by the include statement in https://github.com/microsoft/vcpkg/commit/6b9ac36fcbcad8b2194277508ff2338b57055369

hmm alternatively force c++17 on vtk and update the pegtl dep? (hmm theoretically the find module should already do that.)

hmm alternatively force c++17 on vtk and update the pegtl dep? (hmm theoretically the find module should already do that.)

vtk says it wants pegtl-2, based on its vcpkg.json. It is getting pegtl (not -2) if that happens to be installed, because pegtl-2 installs to
pegtl-2:x86-windows:/include/pegtl-2/tao/pegtl.hpp
and pegtl (non -2) installs to
pegtl:x86-windows:/include/tao/pegtl.hpp
and some other unrelated lib put the root of the include directory on the include path earlier.
I don't know enough about vtk to support or oppose changing the dependency from pegtl from pegtl-2, but since this is not intending to give a different answer I don't want to make that change.

[vcpkg-gfortran] Also not supported on UWP.
warning: The App Container bit must be set for Windows Store apps. The following DLLs do not have the App Container bit set:

    D:\packages\vcpkg-gfortran_x64-uwp\debug\bin\libgcc_s_seh-1.dll
    D:\packages\vcpkg-gfortran_x64-uwp\debug\bin\libgfortran-5.dll
    D:\packages\vcpkg-gfortran_x64-uwp\debug\bin\libquadmath-0.dll
    D:\packages\vcpkg-gfortran_x64-uwp\debug\bin\libwinpthread-1.dll
    D:\packages\vcpkg-gfortran_x64-uwp\bin\libgcc_s_seh-1.dll
    D:\packages\vcpkg-gfortran_x64-uwp\bin\libgfortran-5.dll
    D:\packages\vcpkg-gfortran_x64-uwp\bin\libquadmath-0.dll
    D:\packages\vcpkg-gfortran_x64-uwp\bin\libwinpthread-1.dll

This previously succeeded in CI but the resulting program could not be distributed because it would fail the WACK. (And we could not detect the problem before because it passed skip-dumpbin-checks)

[vcpkg-gfortran] Also not supported on UWP.

Be aware that we had the discussion somewhere already.

Be aware that we had the discussion somewhere already.

I don't necessarily want to relitigate something that has been litigated before but I see little reason in claiming to people that something is available only for it to blow up in their face when they try to ship. Do you have a link to the previous discussion which may have landed on mitigations?

I don't necessarily want to relitigate something that has been litigated before but I see little reason in claiming to people that something is available only for it to blow up in their face when they try to ship. Do you have a link to the previous discussion which may have landed on mitigations?

https://github.com/microsoft/vcpkg/pull/19413#pullrequestreview-956898159
seems like the result was that uwp is already broken but it was never marked as broken.

seems like the result was that uwp is already broken but it was never marked as broken.

Yeah there I said

Given that UWP is already broken for gfortran et al. here, don't worry about UWP interaction in whatever the solution is.

so it seems like this is just documenting that it's broken rather than actually breaking anything.

so it seems like this is just documenting that it's broken rather than actually breaking anything.

That is because the lapack dependency on uwp is fulfilled via clapack.

[lapack-reference]:
warning: Detected outdated dynamic CRT in the following files:
D:\packages\lapack-reference_x86-windows\debug\bin\liblapack.dll:msvcrt.dll
D:\packages\lapack-reference_x86-windows\bin\liblapack.dll:msvcrt.dll
To inspect the dll files, use:
dumpbin.exe /dependents mylibfile.dll

Hm I don't understand why it is necessary to bump the port version of every boost port.

https://github.com/microsoft/vcpkg/pull/29540 and https://github.com/microsoft/vcpkg/pull/29481 touch boost-build that the entire Boost word depends on, but forgot to rerun generate-ports.ps1. Really, only those ports which transitively depend on boost-random should need to be affected here.

All VTK changes removed due to https://github.com/microsoft/vcpkg/commit/8c0fe4a71d074a2682c1984da655fe547a4fdf21 landing.

authors: BillyONeal Neumann-A autoantwort dg0yt walbourn


text:
[netcdf-c] Fix dependency import/export

Fixes #33753 (hdf5 and curl dependencies in exported config).
Amends #30938 (libzip dependency).
Adds curl dependency to feature nczarr.
Replace platform-default-features using platform expression in default-features.
All features tested on x64-linux with vcpkg test-features netcdf-c.

Thanks for the fix!


text:
Update reactiveplusplus to version 2.1.1

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[ ] The "supports" clause reflects platforms that may be fixed by this new version.
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

@microsoft-github-policy-service agree


text:
[zlib-ng] Fix pkg-config file for windows

Fix #39141. Fix the library name for pkg-config is z-ng but output name is zlib-ng[d].lib for windows.
Checklist

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[ ] ~The "supports" clause reflects platforms that may be fixed by this new version.~
[ ] ~Any fixed CI baseline entries are removed from that file.~
[ ] ~Any patches that are no longer applied are deleted from the port's directory.~
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Test
The port usage tests pass on Release and Debug with the following triplets:

x64-windows
x64-windows-static

Thanks for the fix!

authors: BillyONeal WangWeiLin-MV


text:
RxPredictor

Does this occur consistently?
Repro steps:

Version: 0.25.2
OS: win32
OS Release: 10.0.19045
Product: Visual Studio Code
Product Version: 1.91.1
Language: en

Web App for Prescription Predictor

Could you provide issue details and the repro steps?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

authors: AzCode-Bot nturinski presiZHai

repo: microsoft/vscode-azureappservice


text:
VS Code Network requirements

I'm trying to use VS Code on my corporate network.
I would like to check the communication requirements for Azure Account in order to pass through Firewall and Proxy. Could you please tell me?

Communication is via HTTPS

Closing this in favor of https://github.com/microsoft/vscode-azure-account/issues/857

repo: microsoft/vscode-azurefunctions


text:
Resolve using list instead of get

Fixes #3723
Making a HTTP request for each resource is really hurting performance. Ideally we can delay these requests until the user expands the resource or invokes a command on it, but for now I think this is the best solution.
The cache only valid for 3 seconds, long enough to make sure the entire batch of resolve calls can hit the cache. I didn't do anything fancy since I want to validate with the customer that this speeds things up. I figure we can make a util and share this across extensions later.

Actually, you never actually clear the cache. I'm worried that if we delete a function app, the siteCache will still be in the map because we're doing a list, and then a for each over the returned sites list.

Good catche 😄 , it's probably a good idea to clear the cache.
I do want to note that technically delete would work OK since RGs will always re-list the resources and only resolve what it knows about. So having deleted things in the cache wouldn't cause issues for that particular case.
I do think it might cause issues at other times, so it's still a good idea.

Since the release is delayed maybe we merge this and do another round of testing.


text:
Add utility for handling multiple selected nodes

Docker has a similar challenge: https://github.com/microsoft/vscode-docker/blob/main/src/utils/multiSelectNodes.ts
When multiple nodes are selected and an action performed on one of them, we simply ignore those for which the action is not valid.
The only place where we use the "primary" node is in creating a list out of it, if there are no items in the selection list: https://github.com/microsoft/vscode-docker/blob/main/src/utils/multiSelectNodes.ts#L30-L33

Originally posted by @bwateratmsft in https://github.com/microsoft/vscode-azureresourcegroups/pull/516#discussion_r1072395529

The way Docker does things is to depend on context value filters--much the same as we use for context commands launched through the command palette--to ignore nodes for which the action is invalid. This can theoretically end up in all of the selections being ignored, in which case we treat it the same as command palette where nothing is selected (and we prompt).
The real pain about this approach is it forces a given context value to show up in at least three places--once where the tree node is constructed, once in the package.json for controlling where the action is shown, and once in the command to filter for specific context value(s). The latter two are nearly or exactly identical regexs and the duplication of code is error-prone. It might be interesting to try to apply the when clause from the manifest to see what nodes still pass the filter, if it's possible.

Related https://github.com/microsoft/vscode/issues/170248#issuecomment-1582201763

authors: alexweininger bwateratmsft

repo: microsoft/vscode-azuretools


text:
Duplicated launch targets

Maybe this is fixed already but I am unable to find such issue.
Whenever I need to select a launch target I see duplicated entries:

Maybe whenever there is just one target in the project it should be selected by default and no select popup menu should be displayed.

I can still see the duplicated entries in 1.2.1.

I tried to reconstruct  the dublicate entries. But I don´t see it. Are this duplicate launch configurations or execution targets? When is the dialog shown? How does the launch configuration looks like? And which tool versions are used?

When I click on "Debug" on the status bar. I have been observing this for a while now with this project of mine:
https://github.com/Zingam/GunBox
I tried to quickly debug it but couldn't get any idea what was going on. The above screenshot was made on Ubuntu. Here a a couple of screenshot on Windows.
Here I clicked: [all]  "Set the active target to build" on the status bar.

Here I clicked: [Debug] "Select target to launch" on the status bar.

The project contains to executable targets from different projects (see cmake: project outline).
May be it is helps to add the project into the target description.

@KoeMai This is puzzling. I have just one add_executable in the source. Also that other library ThirdParty/glad also appears twice.
I use Visual Studio 2019 mostly and I don't observe that kind of duplicated executable targets there.

These are the debug targets as seen in VS2019 and exactly as expected:

The duplication of targets in the outline happens because I have multiple project commands in my CMakeLists.txt-s. When I removed all project commands but the one in the root CMakeLists.txt the Project outline started to look good.
The structure was:

project 1 in the root CMakeLists.txt adds project 2's and project 3's CMakeLists.txt

project 2 in sub-CMakeLists.txt(contains a library target) addsproject4'sCMakeLists.txt`
project 3 in sub-CMakeLists.txt (contains an executable target)
project 4 in sub-CMakeLists.txt (contains a library target)

I don't think that my CMakeLists.txt are wrong. I would blame the way the tree is constructed.

The CMake server returns a list of projects:
https://cmake.org/cmake/help/v3.16/manual/cmake-server.7.html#type-codemodel
https://cmake.org/cmake/help/v3.16/manual/cmake-file-api.7.html#object-kind-codemodel
And the extension just puts them into the Outliner:
updateCodeModel(model: cms.CodeModelContent|null, exCtx: {launchTargetName: string|null, defaultTargetName: string}) {
    if (!model || model.configurations.length < 1) {
      return;
    }
    this._codeModel = model;
    const config = model.configurations[0];
    const updates: BaseNode[] = [];
    const new_children: BaseNode[] = [];
    for (const pr of config.projects) {
      const item = new ProjectNode(pr.name);
      item.update(pr, {...exCtx, nodesToUpdate: updates});
      new_children.push(item);
    }
    this._children = new_children;

    this._changeEvent.fire(null);
    for (const node of updates) {
      this._changeEvent.fire(node);
    }
  }

I cannot see a reason why the extension should iterate over all projects and their sub-projects. I think it should just use the top-level project (or too-level projects when the extension starts supporting multiple top-level projects).

A simple sample project:
CMakeMultiProject.zip

Thanks for the example.  I created a PR for this.

Ha, I spoke too soon.  I only fixed the build selector.  I need to fix the launch one too.

authors: KoeMai Zingam bobbrow

repo: microsoft/vscode-cmake-tools


text:
return expandedPreset, not preset

Small bug where we were returning the wrong variable from the expandBuildPresetVariables method.
Fixes the testing done here https://github.com/microsoft/vscode-cmake-tools/pull/3905#issuecomment-2311910578.
Also fixes #4011
Thanks @v-frankwang!
@qarni FYI.

@gcampbell-msft @qarni  We verified both issues on CMake Tools: v1.19.47 (pre-release) and they have been fixed:
Actual result：
Issue：https://github.com/microsoft/vscode-cmake-tools/issues/2934

Issue：https://github.com/microsoft/vscode-cmake-tools/issues/4011

authors: gcampbell-msft v-frankwang


text:
STEALING IP WITHOUT YIELDING VALUE

Type: Bug
WHAT IS THIS!!!! I HAVE BEEN WORKING ALL DAY AND YOU HAVE YET TO PRODUCE ANY WELL COMPILING CODE!!! THIS IS CLEAR HALLUCINATION!!! DO NOT REPRINT ANYTHING ELSE BUT INITIALIZING CORRECTLY USING OUR RUNNER AND JSON VERSIONING MESSAGE PASSING SYSTEM PASSING FOR OUR SERIALIZE OBJ PARAM AND THE FUNCTIONALIZED VECTORIZED SERIALIZE_DATAFRAME AND DESERIALIZE_DATAFRAME PASSING DF, AND DATA RESPECTIVELY THESE ALL NEED TO EXACT AND PRECISE AS ABOVE BE DEFINED CORRECTLY IN RUNNER DEF EXACT AND PRECISE IN NEXT ONE SHOT TREE OF THOUGHT RESPONSE!!! MY PATIENCE IS TOO THIN YOU ARE GIVING ME NO RESULTS AND STEALING MY IP. CALVIN THOMAS CODE IP AUTHOR ATTRIBUTION - ALL RIGHTS TO PROFIT AND STRATEGY CONFIDENTIAL IP RESERVED. ANY PERSONS OR OTHERWISE WHO TRAINS OR USES OR YIELDS PROFIT OR NOT DEMINIMUS GAINS FROM USING MY IP CODE WILL IMMEDIATELY BE SUED BY ME CALVIN THOMAS AS THE AUTHOR AND ALL RIGHTS TO PROFIT RESERVED EXACT AND PRECISE AND NOTHING ELSE!!!!
Extension version: 0.21.2024090602
VS Code version: Code 1.93.1 (38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40, 2024-09-11T17:20:05.685Z)
OS version: Windows_NT x64 10.0.22631
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz (8 x 1498)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabledwebnn: disabled_off

Load (avg)
undefined

Memory (System)
11.70GB (1.09GB free)

Process Argv
. --crash-reporter-id f3fa75ea-a304-428b-bfe8-e421882cc06b

Screen Reader
no

VM
33%

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
724cj586:31013169
a69g1124:31058053
dvdeprecation:31068756
dwnewjupytercf:31046870
2f103344:31071589
impr_priority:31102340
nativerepl1:31139838
refactort:31108082
pythonrstrctxt:31112756
flighttreat:31134774
wkspc-onlycs-t:31132770
wkspc-ranged-c:31125598
cf971741:31144450
defaultse:31146405
notype1cf:31150298
5fd0e150:31146321

All caps doesn't get your issues looked at faster. It just makes you come off as angry and makes other less likely to want to assist with your issue.
Can you clarify your problem a bit more? You're seeing completions that are not helpful in your code? Examples would give us actionable scenarios to improve upon

Hi,
I sincerely apologize, I will provide more details later but this is in efforts to automate my own internal reporting to Github internal (for fastest first response) wherein I submit templated prompt if there is error to the VSCode chat interface directly and then it gives solutions (so that when I get alert I can review these or insert best-fitting code dynamically to fix is error raised) that are then matched with prior outcomes from extracting and debug from e.g. json and parquet serialization and deserialization error handling logging file. If there are more than the daily max limits of unanswered responses labeled as hallucinations (trained on my priors of total prompts in my own specialized debug chat running in par. since I started teams wherein max limit is when it interprets as machine refuses direct response with copied lev. distance answers from priors) it sends this prompt automatically. I will try to provide documentation later, but this holds true and is persistent error observed in general over last few years too as recently to troubleshoot there have been looping copying solutions wherein a well-compilable solution in simple python alone has not been derived last 3-4 days running to fix simple testing compilation for my integrating ci/cd code into custom algo.

Without providing my IP on the exact and precise errors from log it will be hard to communicate but let me know if there is a specific hallucination error that I reported as falsely incorrect and I will take a look.

I still don't really understand what you're saying. Is it just that the LLM is giving you bad answers for your use case?

IT IS GIVING PERIODIC BAD ANSWERS WHEREIN IT IS CLASSIFYING AS HALLUCINATING, SINCE AFTER MORE THAN 5-10 ATTEMPTS POTENTIAL CODE CORRECT VERSIONING TURNS OFF OR IGNORES AUTO-SUGG. BUT IN THIS WE SEE THAT IT TERMINATES EARLY VIA SYSTEM MESSAGE WHEREIN IT DOES NOT ACCEPT ANSWERS (COMPLETES EARLY SINCE THE LLM AT POINT-IN-TIME LOADING CHOSE MOST LIKELY EASIEST TO COMPLETE BUT NOT MINIMUM COMPLIANCE REQUIREMENTS SO IT'S NOT ACCEPTED BY MY MODEL EITHER AGAINST INTERNAL COUNTS HANDLING FOR OUTLIERS IN PERF. HANDLING. THEREFORE, THERE IS HALLUCINATIONS BUT IT DOES NOT RISE TO YOUR LEVEL OF CONCERN BUT MAKES MESSAGE PASSING IMPOSSIBLE FOR MY CURRENT CODE ERROR CORRECTING VERSIONING FILING SYSTEM.

I was testing but program just crashed so wasnt able to send diag.

@calvinsthomas sounds like you are using notebooks and seeing bad results – can you confirm? Maybe you can share some of the prompts you used.
The logs are in Show Output Channels > GitHub Copilot Chat

authors: calvinsthomas digitarald lramos15

repo: microsoft/vscode-copilot-release


text:
https://github.com/aalborgi/Wallet-Stealer-tool/blob/main/wallets.cpp

Is your feature request related to a problem? Please describe.

Describe the solution you'd like:

Describe alternatives you've considered:

Additional context:

Closing due to missing details, feel free to reopen once more information has been added.

repo: microsoft/vscode-edge-devtools


text:
Authentication provider sample can't log out

Extension sample
authenticationprovider-sample
VS Code version
1.87.2
What went wrong?

Run the sample extension.
Sign in by running the command and filling in the PAT input.
Sign out from Accounts Menu > Personal Access Token (PAT).

VSCode will say "Successfully logged out" but the item doesn't disappear.

Nice catch, I have a fix out for this.

authors: TylerLeonhardt kyswtn

repo: microsoft/vscode-extension-samples