text:
Capitalize behaviours lesson in listing

Self-explanatory. It was not listing with a capitalized title like the rest of the Advanced lessons in its section.

Thanks @ybur-yug 👍

authors: doomspork ybur-yug

repo: doomspork/elixir-school


text:
いいところ診断の結果に優しさを追加したい

以下の結果を追加したい
'{userName}のいいところは優しさです。あなたの優しい雰囲気や立ち振舞に多くの人が癒やされています。'

これから対応します。

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
two questions: 1. how to set the destination for ego vehicle? 2. how to print the variable?

how to set the destination for ego vehicle?
I did not find the file to set  of destination carla ego vehicle. how to set it?
how to print the variable?
I want to monitor some variables when running simulation, but it seems did not work using 'print(xx)'. are there some other ways to realize?

if set the NUM_WAYPOINTS_AHEAD from 120 to 145，something wrong happened, the ego vehicle cannot work properly, how to fix?

In order to change the goal destination you should look at the carla_gps_op.py and change it there.
in order to print anything you should us: dora logs <DATAFLOW_ID>
To see it printing there.
check the flush=true option in print to see in real time

sorry, I am not clear: 'dora logs <DATAFLOW_ID>' should write to the python script? and where to find '<DATAFLOW_ID>' ? flush=true where to set?

In order to change the goal destination you should look at the carla_gps_op.py and change it there.
in order to print anything you should us: dora logs <DATAFLOW_ID>
To see it printing there.
check the flush=true option in print to see in real time

sorry, I am not clear: 'dora logs <DATAFLOW_ID>' should write to the python script? and where to find '<DATAFLOW_ID>' ? flush=true where to set?

is there any example code?

if set the NUM_WAYPOINTS_AHEAD from 120 to 145，something wrong happened, the ego vehicle cannot work properly, how to fix?

I wouldn't recommend changing the number of waypoint ahead. You should probably revert back.
However, if you really want to you should change make sure that every message using the waypoints are reshaping the data in the right shape with this newly updated number of waypoints.

In order to change the goal destination you should look at the carla_gps_op.py and change it there.

in order to print anything you should us: dora logs <DATAFLOW_ID>

To see it printing there.

check the flush=true option in print to see in real time

sorry, I am not clear: 'dora logs <DATAFLOW_ID>' should write to the python script? and where to find '<DATAFLOW_ID>' ? flush=true where to set?

You should type this in your terminal:
Dora logs c95d118b-cded-4531-a0e4-cd85b7c3916c carla_gps_op

In your Python script make sure to use:
print("test", flush=True)

It seems only something wrong happen, the print can work?
"description should only be set when status_code is set to StatusCode.ERROR"

In order to change the goal destination you should look at the carla_gps_op.py and change it there.

in order to print anything you should us: dora logs <DATAFLOW_ID>

To see it printing there.

check the flush=true option in print to see in real time

sorry, I am not clear: 'dora logs <DATAFLOW_ID>' should write to the python script? and where to find '<DATAFLOW_ID>' ? flush=true where to set?

You should type this in your terminal:
Dora logs c95d118b-cded-4531-a0e4-cd85b7c3916c carla_gps_op

In your Python script make sure to use:
print("test", flush=True)

it seems only work when fail:
description should only be set when status_code is set to StatusCode.ERROR

In order to change the goal destination you should look at the carla_gps_op.py and change it there.

in order to print anything you should us: dora logs <DATAFLOW_ID>

To see it printing there.

check the flush=true option in print to see in real time

sorry, I am not clear: 'dora logs <DATAFLOW_ID>' should write to the python script? and where to find '<DATAFLOW_ID>' ? flush=true where to set?

You should type this in your terminal:
Dora logs c95d118b-cded-4531-a0e4-cd85b7c3916c carla_gps_op

In your Python script make sure to use:
print("test", flush=True)

And the print is not executed in real time

So the print of logs is not in real time and you will have to open and close it to take into account the latest logs. We're working on a better logging system but as of now, this is how we do logging.

You can now check the logs in the out folder.

authors: caixxuan haixuanTao

repo: dora-rs/dora


text:
'overwrite': works only at root level

Describe the bug
Given config does not overwrite
{
  'require': ['ts-node/register/transpile-only'],
  'generates':
    {
      'src/modules/my-first-module/generated-models.ts':
        {
          **'overwrite': true,**
          'schema': 'src/modules/my-first-module/schema.ts',
          'plugins': ['typescript-common', 'typescript-server', 'typescript-resolvers'],
          'config': { 'noNamespace': false, 'contextType': '@graphql-modules/core#ModuleContext' },
        },
      'src/modules/my-second-module/generated-models.ts':
        {
          'overwrite': false,
          'schema': 'src/modules/my-second-module/schema.ts',
          'plugins': ['typescript-common', 'typescript-server', 'typescript-resolvers'],
          'config': { 'noNamespace': false, 'contextType': '@graphql-modules/core#ModuleContext' },
        },
    },
}

this overwrites each
{
  'require': ['ts-node/register/transpile-only'],
   **'overwrite': true,**
  'generates':
    {
      'src/modules/my-first-module/generated-models.ts':
        {
         **'overwrite': true,**
          'schema': 'src/modules/my-first-module/schema.ts',
          'plugins': ['typescript-common', 'typescript-server', 'typescript-resolvers'],
          'config': { 'noNamespace': false, 'contextType': '@graphql-modules/core#ModuleContext' },
        },
      'src/modules/my-second-module/generated-models.ts':
        {
         **'overwrite': false,**
          'schema': 'src/modules/my-second-module/schema.ts',
          'plugins': ['typescript-common', 'typescript-server', 'typescript-resolvers'],
          'config': { 'noNamespace': false, 'contextType': '@graphql-modules/core#ModuleContext' },
        },
    },
}

To Reproduce
"graphql-code-generator": "^0.16.1",
"graphql-codegen-add": "^0.16.1",
"graphql-codegen-time": "^0.16.1",
"graphql-codegen-typescript-common": "0.16.1",
"graphql-codegen-typescript-resolvers": "^0.16.1",
"graphql-codegen-typescript-server": "^0.16.1",

 npx gql-gen

 ubuntu 16, node v8.9.4

#1362 should fix it

Fixed in 0.18.0 🎉

authors: dotansimha kamilkisiela ngmariusz

repo: dotansimha/graphql-code-generator


text:
fix(vue-apollo): keep up with @vue/apollo-composable

keep up with vuejs/vue-apollo@81475da

Thank you @aki77  :) Is that a breaking change in vue-apollo? Do we need to notify users that this change only supported from a specific version of vue-apollo?

Thanks @dotansimha !
This is not a breaking change for users using vue-apollo alone.
But for users using @graphql-codegen/typescript-vue-apollo, this is a breaking change.
So I think we should notify them that @vue/apollo-composable@^4.0.0-alpha.12 is the target.

Got it. I wonder if this needs to be merge right now, since @vue/apollo-composable is still alpha, and I don't think it's a good idea to bump major version for a codegen plugin, based on an alpha API that might change later.

I'm fine with minor upgrades.
Because as a codegen plugin it doesn't introduce any breaking changes to the API.
To begin with, only the alpha version of @vue/apollo-composable exists.
The best option is to keep up with the latest version of @vue/apollo-composable.

Good work. Would love to see this merged anytime soon.
I tried to work with Vue3 in combination with Apollo Client and AWS AppSync but got into trouble setting it up using the generated types from codegen.

This would unlock the possibility to upgrade existing Vue apps that are using this codegen lib to Apollo Client 3. I think it's worth merging and releasing this ASAP.

There is another PR which fixes this bug along with other improvements and fixes to the vue apollo plugin: https://github.com/dotansimha/graphql-code-generator/pull/5007

@P4sca1 Good work!
@dotansimha I think the PR for #5007 should be merged.

Great, thank you all for your amazing contributions. We'll get https://github.com/dotansimha/graphql-code-generator/pull/5007 merged now :)

source: gharchive/pull-request


text:
Incompatible Typescript Cache type when using createInMemoryCache

Describe the bug
When using the latest @graphql-yoga/plugin-response-cache plugin, providing a manually initialized createInMemoryCache cache instance causes a Typescript error:
error TS2322: Type 'import("/workspace/node_modules/@envelop/response-cache/typings/cache").Cache' is not assignable to type 'Cache'.
  The types returned by 'get(...)' are incompatible between these types.
    Type 'PromiseOrValue<ExecutionResult<ObjMap<unknown>, ObjMap<unknown>>>' is not assignable to type 'Promise<ExecutionResult<Record<string, unknown>, ResponseCachePluginExtensions>>'.
      Type 'ExecutionResult<ObjMap<unknown>, ObjMap<unknown>>' is missing the following properties from type 'Promise<ExecutionResult<Record<string, unknown>, ResponseCachePluginExtensions>>': then, catch, finally, [Symbol.toStringTag]

Prior versions of the plugin (1.4.0) did not cause this error.
Your Example Website or App
https://codesandbox.io/p/sandbox/laughing-keldysh-ffhp3k?file=%2Findex.ts%3A4%2C20
Steps to Reproduce the Bug or Issue
Create a Typescript instance of Yoga using the useResponseCache plugin, with the cache option set to a cache instance created with createInMemoryCache.
Expected behavior
The server should start normally.
Screenshots or Videos
No response
Platform
Typescript
Additional context
No response

yes having the same problem

I'm having the same problem.
"@envelop/response-cache-redis": "^3.3.0", "@graphql-yoga/plugin-response-cache": "^2.1.1", "ioredis": "^5.3.2",

A possible workaround while it's being fixed is:
const cache = createInMemoryCache() as UseResponseCacheParameter['cache'];

You can try @graphql-yoga/plugin-response-cache@2.1.2-rc-20230920111722-2d9abd25 preview version if you want to verify the fix is working.

authors: Aurumdev952 Don-Cryptus EmrysMyrddin aidenfoxx gthau

repo: dotansimha/graphql-yoga


text:
Updating credit multipliers for MacOS under Velocity

Description
Adds missing multiplier for elite-xl MacOS machines (available over gen2 infrastructure)
Types of changes

[ ] House cleaning (change at project level, like tooling revamp, refactors, etc)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (non-breaking change which improves existing functionality)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (something that would cause existing functionality to not work as expected)
[ ] Documentation (self-explained)

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@17d1263). Click here to learn what that means.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #61   +/-   ##
=======================================
  Coverage        ?   86.72%
=======================================
  Files           ?       11
  Lines           ?      422
  Branches        ?        0
=======================================
  Hits            ?      366
  Misses          ?       56
  Partials        ?        0

Impacted Files
Coverage Δ

bitrise_reports/metrics.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 17d1263...75297e4. Read the comment docs.

authors: codecov-commenter ubiratansoares

repo: dotanuki-labs/bitrise-reports


text:
dotenvx.com vs dotenv.org?

So there's https://dotenv.org/ (the TOS say Dotenv ("Company")) and https://dotenvx.com/ (the TOS say Dotenvx ("Company")). There are different Github orgs, different X accounts, different "companies" (but without any details). Both use the same logo and the same tagline "dotenv. better.".
Neither project references the other. Are both legit? What's the relationship? Is one a scam? It all looks suspicious, perhaps unnecessarily. Some clarification would be useful.
The projects that are about secret management are a bit too secretive themselves for my taste.

Thanks for clarification. I was confused by the user-facing websites. (I can imagine others might be as well.)
The repos themselves give a somewhat clearer picture.

repo: dotenvx/dotenvx


text:
CentOS Kernel-Devel issue

I see that vbguest tries to install the same kernel-devel package as the active kernel. However for CentOS 6.5, once there is a kernel update available, it seems the old kernel-devel is no longer available. This causes vbguest to fail to install.
I am using the chef/centos-6.5 base image, so have got around this in my Vagrantfile by doing:
class ChefCentosInstaller < VagrantVbguest::Installers::Linux
  def install(opts=nil, &block)
    communicate.sudo('sudo yum install -y kernel kernel-devel', opts, &block)
    # calling `super` will run the installation
    # also it takes care of uploading the right iso file into the box
    # and cleaning up afterward
    super
  end
end

And adding this into my vagrantfile configuration:
  config.vbguest.installer = ChefCentosInstaller

This forces both kernel and kernel-devel to update to the same version.
I suspect the issue is in https://github.com/dotless-de/vagrant-vbguest/blob/master/lib/vagrant-vbguest/installers/redhat.rb somewhere....
Is it too aggressive to force a base image to update kernel by default (on provision)?!

FYI, running into this same issue with CentOS 7.0 (from the official chef/centos-7.0 box). Ended up working around it entirely by mounting the shared folder with NFS (Windows users can use SMB instead).
Since this is a workstation-specific issue, I placed it in the ~/.vagrant.d/Vagrantfile file. It appears this is a leftover from vagrant's v1 days, but still applies.
Not exactly a fix for this issue, but it's a temporary workaround for anyone else needing it.

I can confirm the 6.6 box fixes this problem.
I still personally believe that the vbguest updater should ensure it has the latest kernel if it requires kernel-devel... and if it detects that kernel has been updated, it should reboot.
The fact it errors if it cannot update, to me, feels like a bug. ITs not impossible to update, it just needs to jump through a small hoop ;)

@njt1982, I agree... The plugin should handle this seemlessly

I ended up hacking together a plugin/middleware fix for this issue and figured I'd post it here in case anyone else is interested. Pretty sure there's a cleaner/better way to do this, but this solution worked for me for now. Just add this to the bottom of your Vagrantfile:
module UpdateCentOSKernel
    class UpdateCentOSKernelPlugin < Vagrant.plugin('2')
        name 'update_centos_kernel_plugin'

        # update yum after first boot when provisioning
        action_hook(:update_yum, :machine_action_up) do |hook|
            hook.after(VagrantPlugins::ProviderVirtualBox::Action::CheckGuestAdditions, UpdateCentOSKernel::Middleware::KernelUpdater)
        end
    end

    module Middleware
        class KernelUpdater
            @@rebooted = {};

            def initialize(app, env)
                @app = app
            end

            def call(env)
                @env = env
                @vm = env[:machine]
                @ui = env[:ui]
                self.update_kernel()
            end

            def update_kernel()
                if !@@rebooted[@vm.id]
                    @@rebooted[@vm.id] = true

                    @ui.info 'Updating kernel'
                    @vm.communicate.sudo('yum install -y kernel kernel-devel') do |type, data|
                        if type == :stderr
                            @ui.error(data);
                        else
                            @ui.info(data);
                        end
                    end

                    self.reboot()
                end
            end

            def reboot()
                @ui.info('Rebooting after updating kernel')
                simle_reboot = Vagrant::Action::Builder.new.tap do |b|
                    b.use Vagrant::Action::Builtin::Call, Vagrant::Action::Builtin::GracefulHalt, :poweroff, :running do |env2, b2|
                        if !env2[:result]
                            b2.use VagrantPlugins::ProviderVirtualBox::Action::ForcedHalt
                        end
                    end

                    b.use VagrantPlugins::ProviderVirtualBox::Action::Boot
                    if defined?(Vagrant::Action::Builtin::WaitForCommunicator)
                        b.use Vagrant::Action::Builtin::WaitForCommunicator, [:starting, :running]
                    end
                    b.use VagrantVbguest::Middleware
                end
                @env[:action_runner].run(simle_reboot, @env)
            end
        end
    end
end

I modified the redhat.rb and got close, but couldn't automate the reboot / reload after the kernel update so that the module could finish installing the Guest Additions.

I found a simple solution for the likes of chef/centos-6.5
vagrant plugin uninstall vagrant-vbguest

So I guess the issue for this plugin is that it optimistically tries to upgrade the guest additions but this can fail on some OS in situations where the old version would do just fine.
So maybe the plugin should be pessimistic by default (user's add this to ~/vagrant.d/Vagrantfile)
config.vbguest.auto_update = false

Or it could automagically detect if upgrading will fail or try installing upgrade dependencies before uninstalling the existing version so it fails back to that
To the credit of this plugin the warning it gives is pretty good
Removing existing VirtualBox non-DKMS kernel modules[  OK  ]
Building the VirtualBox Guest Additions kernel modules
The headers for the current running kernel were not found. If the following
module compilation fails then this could be the reason.
The missing package can be probably installed with
yum install kernel-devel-2.6.32-431.el6.x86_64

Building the main Guest Additions module[FAILED]

Still an issue; this came up for the first time for me with a CentOS 6.7 box. Since #153 is closed, this should be too presumably.  As per the final comment on #153, did anyone attempt creating a plugin for updating the kernel?  A quick look at https://vagrant-lists.github.io/plugins.html suggests no.
Manually updating the kernel (or the box) isn't that much of a pain otherwise.

There's a better way - #223 .

repo: dotless-de/vagrant-vbguest

license: mit

license_source: bigquery


text:
mixins with same name but different argument count get imported twice

I have following mixins
.ellipsis(@width: none) {
width: @width;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.ellipsis(@width_type, @width) {
test: @arguments;
@width_type: @width;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
And following selectors:
table.consumption_entry {
th {
.ellipsis(max-width, 85px);
}
}
What i get:
table.consumption_entry th {
width: max-width;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
test: max-width 85px;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
Expected output:
table.consumption_entry th {
test: max-width 85px;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
Notice also on the error case the missing "max-width: 85px" eventthough the @arguments clearly has them.
How can the mixin match for only one argument aswell?

inside a mixin if you have
.a(@arga, @argb) {
   @arga : @argb;
}

you are just assigning argb to arga... not outputting the rule.
With regards mixins, you are right that it should only match the one with 2 arguments, we need to port the (very) recent commit from less.js to allow
.a(...) {
  variable: @arguments;
}

In order that it is still possible to use the arguments var effectively.

is there any way to get
@arga: @arb
to output?
This should be documented somewhere. Either that is it an assignment or not printed...

Not that I know of. If you have a finite number of cases you could use
guards.
Its hacky but you could also try
Border: ~"red; @{arga}:@{argb}";

But its a hack and I've never seen anyone need this. What's the use case?

@agatronic Pretty much as described. I want to be able to be able to let the user decide what kind of width he wants. Fixed or variable until a max-width. In this case overflow and ellipsis only make sene if there is a width set, else the element will expand to fit the text..
Generally speaking, the use case is whenever the user should be able to specify a property as variable. And not needing to write different mixins for all the combinations.

for reference on variadic arguments...
https://gist.github.com/1933613
Note that dotless currently has less.js 1.2.2 behaviour where only a minimum number of arguments is imposed.

repo: dotless/dotless


text:
Multiple dotless sections in web.config on upgrade

When upgrading dotless through NuGet an additional dotless section is added to the web.config file if any of the attributes have been changed. This causes an internal server error as the web.config file is no longer valid.
Steps to reproduce

Install dotless 1.4.0 from NuGet
Change one of the attributes in web.config from its default (e.g. set cache="false")
Update dotless through NuGet to 1.4.1

Web.config after initial install
<configuration>
  <configSections>

  </configSections>
  <dotless minifyCss="false" cache="false" web="false" />
</configuration>

Expected result after update
<configuration>
  <configSections>

  </configSections>
  <dotless minifyCss="false" cache="false" web="false" />
</configuration>

Actual result after update
<configuration>
  <configSections>

  </configSections>
  <dotless minifyCss="false" cache="false" web="false" />
  <dotless minifyCss="false" cache="true" web="false" />
</configuration>

This seems to happen consistently across 5 different web apps with both Visual Studio 2012 & 2013. It doesn't appear to happen if the attributes are left as the defaults.

Meh, still needs some work. When I tested the XDT transform, things went smoothly. Now that I'm actually upgrading dotless in one of my projects, the <dotless /> tag was incorrectly replaced.

authors: martinsteel rytmis


text:
Restore nuget packages on mac in Xamarin.forms project

So we have a Xamarin.forms project, where we try to update to latest version of bluetooth le, to prepare for MAUI later.
On windows and android everything works perfectly, I can restore packages, build and bluetooth LE works.
But on Mac when I try to restore packages in my Xamarin.forms project, it comes with error:
"error NETSDK1045: The current .NET SDK does not support targeting .NET Core 6.0.  Either target .NET Core 5.0 or lower, or use a version of the .NET SDK that supports .NET Core 6.0."
I have found a workaround, if I remove all references to Plugin.Ble, and restore then it restore everything correct, afterwards I can build and deploy.
It is easy to reproduce if you have macbook (At least M1) and visual studio for mac. By creating empty Xamarin.forms project, and add Plugin.Ble to iOS and Forms project, try it out.
I have tried to enable and disable "Build with MSBuild on mono", both with same result.
Off topic:
I actually have 2 problems in the end, because if I restore without references, and afterwards build. Then Xamarin.iOS is build as .netstandard project, and not XamarinIOS10, meaning adapter and so on is not implemented. On windows it does build as XamarinIOS10, so maybe there is more problems in the Plugin.BLE project file target platforms on mac ?
But I will create another ticket on that, when restore is fixed.
Steps to reproduce

Create empty Xamarin.forms project

Add Plugin.Ble into solution

Add reference to project into iOS and Forms project.

Try to restore

Expected behavior
Restore packages without problems
Actual behavior
Fail with:
"error NETSDK1045: The current .NET SDK does not support targeting .NET Core 6.0.  Either target .NET Core 5.0 or lower, or use a version of the .NET SDK that supports .NET Core 6.0."
Crashlog
Configuration
Visual studio for mac version: 17.5.6
dotnet --info:
.NET SDK:
Version:   7.0.302
Commit:    990cf98a27
Runtime Environment:
OS Name:     Mac OS X
OS Version:  13.4
OS Platform: Darwin
RID:         osx.13-arm64
Base Path:   /usr/local/share/dotnet/sdk/7.0.302/
Host:
Version:      7.0.5
Architecture: arm64
Commit:       8042d61b17
.NET SDKs installed:
6.0.408 [/usr/local/share/dotnet/sdk]
7.0.302 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.16 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.16 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download

Hi @EhMidtJyde,
I'm the friendly issue checker.
It seems like (37.50 %) you haven't used our issue template :cry: I think it is very frustrating for the repository owners, if you ignore them.
If you think it's fine to make an exception, just ignore this message.
But if you think it was a mistake to delete the template, please close the issue and create a new one.
Thanks!

This seems very similar to my issue, in https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le/issues/702

Fail with: "error NETSDK1045: The current .NET SDK does not support targeting .NET Core 6.0. Either target .NET Core 5.0 or lower, or use a version of the .NET SDK that supports .NET Core 6.0."
[..]
Visual studio for mac version: 17.5.6

This error is sort of a known problem with VS4Mac. However, I have only seen it with mixed solutions (.NET6 and classic Xamarin), not with Xamarin-only solutions.
Can you update to VS for Mac v17.6, and check if it still occurs? It may help to add
<BuildWithMSBuildOnMono>true</BuildWithMSBuildOnMono>

to your Xamarin.Forms project.

Fail with: "error NETSDK1045: The current .NET SDK does not support targeting .NET Core 6.0. Either target .NET Core 5.0 or lower, or use a version of the .NET SDK that supports .NET Core 6.0."
[..]
Visual studio for mac version: 17.5.6

This error is sort of a known problem with VS4Mac. However, I have only seen it with mixed solutions (.NET6 and classic Xamarin), not with Xamarin-only solutions.
Can you update to VS for Mac v17.6, and check if it still occurs? It may help to add
<BuildWithMSBuildOnMono>true</BuildWithMSBuildOnMono>

to your Xamarin.Forms project.

I have 17.6 now, still and issue.
Have tried MS build mono without luck.
So looks like we can only wait for VS/Nuget to fix it, or go MAUI.
We hoped to update Plugin.BLE to latest before going to convert to MAUI.
Worst part of all is, everything works on windows, for both iOS and Android

So looks like we can only wait for VS/Nuget to fix it, or go MAUI.

Well, I can actually not reproduce your problem. Using the Plugin.BLE nupkg (v3.0.0-beta.4) in a pure Xamarin.Forms project works well for me, also with VS for Mac.

Steps to reproduce
1. Create empty Xamarin.forms project

2. Add Plugin.Ble into solution

3. Add reference to project into iOS and Forms project.

4. Try to restore

Could you be more precise about the repro?
About step 2: You don't add a package reference to a solution, but to a project. It should only be needed in the Forms base project (.NET Standard), not the iOS or Android projects.
About step 3: Reference to which project? The Plugin.BLE package should only be added to the Froms project, not the iOS one.

So looks like we can only wait for VS/Nuget to fix it, or go MAUI.

Well, I can actually not reproduce your problem. Using the Plugin.BLE nupkg (v3.0.0-beta.4) in a pure Xamarin.Forms project works well for me, also with VS for Mac.

Steps to reproduce
1. Create empty Xamarin.forms project

2. Add Plugin.Ble into solution

3. Add reference to project into iOS and Forms project.

4. Try to restore

Could you be more precise about the repro?
About step 2: You don't add a package reference to a solution, but to a project. It should only be needed in the Forms base project (.NET Standard), not the iOS or Android projects.
About step 3: Reference to which project? The Plugin.BLE package should only be added to the Froms project, not the iOS one.

I add your repo to solution (Not as nuget, but all source files, and add as reference and not nuget in 3.)
We more or less only use Plugin.BLE in native, we have combi project atm. since we'r converting to forms atm (To get easiere to MAUI later) But result is same if I add reference in iOS or only forms. Both give same error.

Could you be more precise about the repro?
About step 2: You don't add a package reference to a solution, but to a project. It should only be needed in the Forms base project (.NET Standard), not the iOS or Android projects.
About step 3: Reference to which project? The Plugin.BLE package should only be added to the Froms project, not the iOS one.

2. I add your repo to solution (Not as nuget, but all source files, and add as reference and not nuget in 3.)

Ok, misunderstood this part. So, yeah, this will probably not work at present. Building the full Plugin.BLE solution with VS4Mac does not work either currently. Blame Microsoft. I hope they will finally fix their tooling on Mac at some point. If you find any workaround, please let us know.

Could you be more precise about the repro?
About step 2: You don't add a package reference to a solution, but to a project. It should only be needed in the Forms base project (.NET Standard), not the iOS or Android projects.
About step 3: Reference to which project? The Plugin.BLE package should only be added to the Froms project, not the iOS one.

2. I add your repo to solution (Not as nuget, but all source files, and add as reference and not nuget in 3.)

Ok, misunderstood this part. So, yeah, this will probably not work at present. Building the full Plugin.BLE solution with VS4Mac does not work either currently. Blame Microsoft. I hope they will finally fix their tooling on Mac at some point. If you find any workaround, please let us know.

Okey fair, maybe we'r able to make workaround where we only edit Plugin.BLE on windows, since we don't touch that solution much.

At least it’s not just me!On 3 Jul 2023, at 10:18, Janus Weil @.***> wrote:
Could you be more precise about the repro?
About step 2: You don't add a package reference to a solution, but to a project. It should only be needed in the Forms base project (.NET Standard), not the iOS or Android projects.
About step 3: Reference to which project? The Plugin.BLE package should only be added to the Froms project, not the iOS one.

I add your repo to solution (Not as nuget, but all source files, and add as reference and not nuget in 3.)

Ok, misunderstood this part. So, yeah, this will probably not work at present. Building the full Plugin.BLE solution with VS4Mac does not work either currently. Blame Microsoft. I hope they will finally fix their tooling on Mac at some point. If you find any workaround, please let us know.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

So...I've added a Maui sample. It's Android only at the moment and a very simple implementation. It simply lists the devices it's found, showing ID, Device ID and Advertisement data.
You have to enable all Bluetooth and location permissions, but it works for me. I'm using macOS on an M1 MacBook Air, with VS2023 and a Samsung A8 tablet.
It lists all the devices it can see, which is a massive step forward for me. It looks like most of my problems were related to MvvMCross, rather than PlugIn.BLE.
https://github.com/IanBUK/dotnet-bluetooth-le
That's my fork, feel free to have a play.

So...I've added a Maui sample. It's Android only at the moment and a very simple implementation. It simply lists the devices it's found, showing ID, Device ID and Advertisement data.
You have to enable all Bluetooth and location permissions, but it works for me. I'm using macOS on an M1 MacBook Air, with VS2023 and a Samsung A8 tablet.
It lists all the devices it can see, which is a massive step forward for me. It looks like most of my problems were related to MvvMCross, rather than PlugIn.BLE.
https://github.com/IanBUK/dotnet-bluetooth-le
That's my fork, feel free to have a play.

Our problem is only on Xamarin, we tried creating a clean MAUI project, we don't have the issues there.
So this is only Xamarin issue.

authors: EhMidtJyde IanBUK janusw smsissuechecker

repo: dotnet-bluetooth-le/dotnet-bluetooth-le


text:
"Problems with route value invalidation": This paragraph is missing explanation

Description
The paragraph sub title reads: "The following code shows an example of a URL generation scheme that's not supported by routing:" — yet, the text following the example doesn't fulfill the heading's promise: it doesn't explain exactly what in these two examples is not supported and why.
Page URL
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-9.0#problems-with-route-value-invalidation
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/fundamentals/routing.md
Document ID
86aeab13-1c25-9fc1-4e56-0390cb40c242
Article author
@tdykstra

Associated WorkItem - 294099

The desire is to have the culture parameter always accepted as an ambient value. However, the culture parameter is not accepted as an ambient value because of the way required values work:
In the "default" route template, the culture route parameter is to the l

So "changes to controller won't invalidate culture" is interchangeable with "not supported"?

authors: Rick-Anderson SetTrend


text:
Clarify RP conventions with Razor components

Fixes #16798
I think this is correct, but I haven't tested the first scenario (routeable components) myself. The second scenario (embedded) is obviously true.

@Rick-Anderson Let's do this one, too. It's very straightforward ... just saying that components are only indirectly effected by RP conventions when the component is embedded in a page.

I tested the routable scenario with a page route convention and a routable Razor component, and the test result reflects the concept described. Of course, an embedded non-routable component is like anything else on a page controlled by a convention.


text:
change this sample to use file scoped namespace

change this sample to use file scoped namespace like the other samples in the page

 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: prjseal sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: dnfadmin prjseal


text:
Dispose CTS in PostEvictionCallback

Fixes #28952

Internal previews

📄 File
🔗 Preview link

aspnetcore/performance/caching/memory.md
Cache in-memory in ASP.NET Core

@tdykstra  lets get @Tratcher  to approve this.

authors: Rick-Anderson tdykstra


text:
Configuring owned type properties independently of the owner

I'm implementing an Owned type with EFC6.
I'd like to ensure a class can only be used as an Owned type and has a consistent data shape, regardless of the owning class.
I want to use the IEntityTypeConfigurations as I have with all my other entities.  It seems I can configure the owned class using annotations.  As an example:
    [Owned]
    public class Thingie
    {
        [MaxLength(50)]
        [Unicode(false)]
        [Required]
        public string Name { get; private set; }
        [MaxLength(4000)]
        [Unicode(true)]
        public string Comment { get; private set; }
    }

The configuration example on this page shows configuring the entity through the owning entity:
modelBuilder.Entity<DetailedOrder>().OwnsOne(
    p => p.OrderDetails, od =>
    {
        od.WithOwner(d => d.Order);
        od.Navigation(d => d.Order).UsePropertyAccessMode(PropertyAccessMode.Property);
        od.OwnsOne(c => c.BillingAddress);
        od.OwnsOne(c => c.ShippingAddress);
    });

But this seems to encourage, or at least allow, the owning type to determine the configuration for the owned type.  Without using the class and property annotations, referencing the owned type in another model throws this message:

The entity type 'Thingie' cannot be configured as non-owned because it has already been configured as a owned.  Use the nested builder in OwnsOne or OwnsMany on the owner entity type builder to further configure this type. If you want to override previous configuration first remove the entity type from the model by calling 'Ignore'

Can you post an example of how to configure the owned type through an IEntityTypeConfiguration class, independently of the owning type?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d02e6748-42e0-000a-4945-42cd05a0b875
Version Independent ID: e3effbd0-07f2-423d-4032-1722e75adb37
Content: Owned Entity Types - EF Core
Content Source: entity-framework/core/modeling/owned-entities.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: avickers

@wdhenrik This is not currently supported--make sure to vote (👍) for https://github.com/dotnet/efcore/issues/15681, which is tracking this.

authors: ajcvickers wdhenrik


text:
Unable to connect websocket

I use third party tool to connect my mqtt server and it can connect successfully.
Here is my connect setting in the mqtt tool.
https://imgur.com/a/HprXrKc
But when I try connect in c#, it would show error message:
Unable to connect the remote server, the request was aborted: Could not create SSL/TLS secure channel.
How to implement as MQTT Explorer?
OS：Windows server 2012 R2
.Net：.NET FrameWork 4.7
using MQTTnet;
using MQTTnet.Client;
using MQTTnet.Client.Connecting;
using MQTTnet.Client.Options;

public override void Run()
{
	var option = new MqttClientOptionsBuilder()
					.WithWebSocketServer("wss://mymqttserver:443")
					.WithClientId(Guid.NewGuid().ToString())
					.WithTls(new MqttClientOptionsBuilderTlsParameters()
					{
						AllowUntrustedCertificates = true,
						UseTls = true,
						SslProtocol = SslProtocols.Tls12,
						CertificateValidationCallback = delegate { return true; },
					})
					.WithCleanSession()
					.Build();
    var mqtt = new MqttFactory().CreateMqttClient() as MqttClient;
    mqtt.ConnectAsync(option).Wait();

	string convertMsg = JsonConvert.SerializeObject("Mqtt Connect Successfully!!");

	var appMsg = new MqttApplicationMessage();
	appMsg.Payload = Encoding.UTF8.GetBytes(convertMsg);
	appMsg.Topic = "myTopic";
	appMsg.QualityOfServiceLevel = MqttQualityOfServiceLevel.AtLeastOnce;
	appMsg.Retain = false;

	mqttClient.PublishAsync(appMsg).Wait();
}

I assume the question is answered. If not please reopen the ticket.

repo: dotnet/MQTTnet


text:
Vulkan IsDeviceExtensionPresent doesn't discriminate caches by device

Summary
When discovering the available device extension, the device handle we're obtaining the extension cache for is not stored in the hash set (i.e. it should be a HashSet<(Device, string)> or Dictionary<Device, HashSet<string>>). This could lead to an extension being incorrectly reported as present for one logical device because the cache was previously populated using another logical device.
Comments
As discussed in #1563

Nevermind, fixed by #1563


text:
Remote Code Execution Vulnerability

The current Microsoft.Data.SqlClient packages (release 5.1.2 & preview 5.2.0-preview3.23201.1) have Remote Code Execution Vulnerability CVE-2023-36414 through a dependency on Azure.Identity 1.7.0/1.8.0.
This also affects downstream packages such as Microsoft.EntityFrameworkCore.SqlServer.
You can fix this by updating to Azure.Identity 1.10.2 or later.

And in 5.1.4 as I understand it?

authors: ErikEJ albahari

repo: dotnet/SqlClient


text:
There seems to be a difference in the way Microsoft.Data.SqlClient treats Decimal values when compared to System.Data.SqlClient

I have a .Net framework solution that runs a Chi Square test on a sql table and creates another sql table with its values. The P value that this test creates are Decimal values and the table that the program creates contains a column for it with Decimal(20,13) as its datatype.
Sometimes, the program calculates P values that have more than 13 decimal places but the value never exceeds the precision of 20.
When this happens and my program inserts these values into the sql table, the value is just truncated after the 13th decimal place.
Now I ported my solution to .Net Core and I started using Microsoft.Data.SqlClient instead of System.Data.SqlClient. Nothing else has changed in terms of the queries that the program runs. But what I'm noticing here is that in cases where there are more than 13 decimal places, the values are round up/down. Why is there a difference in the way decimal values are treated between the two packages? I tried finding any information on this online. If anyone could explain this, I'd really appreciate it.
I do know the default behavior of SQL server is to round values. But if that's the case, why doesn't it round when I'm using System.Data.SqlClient?

You can enable old behaviour by setting this App Context Switch:
AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.TruncateScaledDecimal", true);
More info: https://learn.microsoft.com/en-us/sql/connect/ado-net/appcontext-switches?view=sql-server-ver16#enabling-decimal-truncation-behavior

This is exactly what I was looking for. Thanks, @cheenamalhotra.

Closing as answered.

authors: Joel-VT cheenamalhotra


text:
[WebToolsE2E][Aspire] Building version 9.0.0 of AspireWithPython fails with an error: " 'Aspire.Hosting.PythonAppResourceBuilderExtensions.AddPythonApp()' is for evaluation purposes only and is subject to change or removal in future updates."

REGRESSION INFO: worked in main branch [Aspire 9.0.0 rc 1]
INSTALL STEPS

Clean machine: Win11 x64 23h2 ENU
Install VS 17.12 Preview 4
Install Python [3.13.0]
Install Docker Desktop
Install azd [1.10.3]

REPRO STEPS

Clone aspire-samples repo, checkout to UpdateTo9GA branch
Add aspire 9.0.0 feed/mapping to nuget.config
Open samples\AspireWithPython and build

ACTUAL
'Aspire.Hosting.PythonAppResourceBuilderExtensions.AddPythonApp(Aspire.Hosting.IDistributedApplicationBuilder, string, string, string, params string[])' is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.

NOTE

This issue does not reproduce on aspire-samples main branch [Aspire 9.0.0 rc 1]

EXPECTED
Building project without any errors.

This is by design, we marked the API as experimental in Aspire 9 because it's unfinished. See https://github.com/dotnet/aspire/issues/6298

@DamianEdwards we should update the sample to ignore the warning in source.

When the samples are updated for 9.0 GA, we will 😄

Fixed

Not repro on main branch

authors: DamianEdwards davidfowl v-sherryfan

repo: dotnet/aspire-samples


text:
JSON Schema for manifest.

Addresses #54
This is still a work in progress. Building out the validation rules in the schema and adding test cases to cover it. I think we are going to have to use Newtonsoft.Json.Schema for the unit tests for now.
Microsoft Reviewers: Open in CodeFlow

How do you expresss the extensibility of the types?

Good question. Today that app model allows people to define their own resource types in the manifest. So technically "myresource.that.no.one.understands.v0" is technically fine - and other than verifying that it has a value in the "type" field no further validation could be done.
I've updated the oneOf clause to include a generic resource type that includes any object that has a type field as a fallback. However if the resource is captured by one of the earlier conditions with a defined resource type it still validates fine (the test cases cover this).

/azp run

/backport to release/8.0

authors: davidfowl mitchdenny

repo: dotnet/aspire


text:
Support callback, custom config key and publishing for parameters.

Description
See #4429 for details.
Fixes #4429
Checklist

Is this feature complete?

[ ] Yes. Ready to ship.
[X] No. Follow-up changes expected to support new manifest value

Are you including unit tests for the changes and scenario tests if relevant?

[X] Yes
[ ] No

Did you add public API?

[X] Yes

If yes, did you have an API Review for it?

[X] Yes
[ ] No

Did you add <remarks /> and <code /> elements on your triple slash comments?

[ ] Yes
[X] No

[ ] No

Does the change make any security assumptions or guarantees?

[ ] Yes

If yes, have you done a threat model and had a security review?

[ ] Yes
[ ] No

[X] No

Does the change require an update in our Aspire docs?

[X] Yes

Link to aspire-docs issue: none yet

[ ] No

Microsoft Reviewers: Open in CodeFlow

Any thoughts on supporting a Func<IServiceProvder, Task> variant?

Thanks once again for the contribution @davidebbo

@mitchdenny per discussion with @davidfowl, we decided not to tackle async at this time, though this could be a future thing (it does look hard!).
Note that per https://github.com/dotnet/aspire/issues/4429#issuecomment-2335197079 and discord chat, we'll be making some design changes for publishing the value, so I'll be evolving the PR.

/azp run

/azp run

cc @vhvb1989 @ellismg

Filed https://github.com/Azure/azure-dev/issues/4359

@davidebbo @davidfowl @mitchdenny is it safe to asume that a default.value will never be set as secure ?, like:
"param-with-value": {
      "type": "parameter.v0",
      "value": "{param-with-value.inputs.value}",
      "inputs": {
        "value": {
          "type": "string",
          "secret": true,
          "default":{
            "value": "default value for param"
          }
        }
      }
    },

See the "secret": true,  there.
I am working on making azd to fail on this case as per: https://learn.microsoft.com/azure/azure-resource-manager/bicep/linter-rule-secure-parameter-default

But I am wondering if the AppHost is even allowing this or not?  (maybe is blocked in AppHost so I don't even need to worry)?

@vhvb1989 we do not block it today, but I agree that we should. So I think we should allow:
var foo = builder.AddParameter("foo", value: "somesecret", secret: true);

as this only uses the value at runtime, but not:
var foo = builder.AddParameter("foo", value: "somesecret", publishValueAsDefault: true, secret: true);

which results in having the secret in the manifest.
@davidfowl @mitchdenny do you agree? If so, can make a follow-up change to prevent this. e.g. an error like the 'publishValueAsDefault' and 'secret' flags are mutually exclusive, to prevent saving a secret to the manifest

I sent #5891 to make this change.

@vhvb1989 This is now blocked in AppHost, so you should not encounter this unless people mess with their manifest by hand,

authors: davidebbo davidfowl mitchdenny vhvb1989


text:
fix curl command for download deb package

fix curl command for download deb package in case installation in Ubuntu

Thanks @namax - all of the dl commands have been updated to use wget.

hi @leecow
thank you for the reply. I would like to help you guys,  if you have any "first time" issues just let me know.

Thanks, @namax ! You can see the updates in https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.5-download.md. Would you mind having a look before I prop them to the main website?

Sure. What exactly do I need to do? Just review the text and the commands for typos?

@leecow
Eg this link is not found  -
SDK Binaries  for windows 32 bit
https://download.microsoft.com/download/1/1/0/11046135-4207-40D3-A795-13ECEA741B32/dotnet-sdk-2.1.4-win-x86.zip

Thanks for the catch @namax.
Have a look at the contributing doc for the best places to finds issues to coding issues to work on.

Than you @leecow  I will read the document, but how I  should to propose  that I would like to work on some issue? Or I can just write in the comments? So I don't find out in the end of fixing some issue that somebody did earlier.
I found another one
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
Seems this is incorrect -qO-

Issues that no one is working on are marked "up for grabs". Commenting in the issue that you are working on it will be enough.
With respect to wget -qO-, specifically the -O- portion; this saves the contents of the file to STDOUT which allows it to be directly piped to the gpg command.

authors: leecow namax

repo: dotnet/core


text:
Add link to new workload set documentation

The markdownlint errors were already in this text before this PR.

@rbhanda @leecow @baronfel
I fixed the preexisting Markdownlint errors, so this is ready to be merged now.


text:
Port normalized equivalent of YieldProcessor from CoreCLR

Port https://github.com/dotnet/coreclr/pull/13670
Port any other PRs that fix relevant issues referenced in https://github.com/dotnet/coreclr/issues/13388

Nice to have, but it is not clear that it would have any significant impact, not likely to happen until a significant issue is shown to substantiate the work

@MichalStrehovsky is this fixed?

This is in reference to #7569 (for the future me, since I failed to call this issue out in the pull request).
I left this open because I'm not sure how important it would be to migrate off of YieldProcessorNormalizedForPreSkylakeCount to the new scheme with YieldProcessorNormalizationInfo.
E.g. we're not exposing the OptimalMaxSpinWaitsPerSpinIteration on System.Threading.Thread but instead normalize the spin number passed to RhSpinWait. That's not what CoreCLR does and I wasn't sure how much that matters.
@kouvel would know but he's out right now and this is going to get lost in his mailbox.

Switching off of the pre-Skylake spin scheme may also require retuning spin-waits with large spin counts. Where applicable, perhaps that could be done one component at a time in the future along with porting the spin scheme for the component from coreclr. I don't think it's critical though.

authors: MichalStrehovsky Suchiman kouvel

repo: dotnet/corert


text:
Investigate LLVM WebAssembly backend

We should evaluate whether the LLVM WebAssembly backend is an improvement over Emscripten and if so, whether we can switch to it.
Discussion below migrated from #4658

@blealtan
Have you considered LLVM wasm target? Though it's in experimental state, emscripten itself is not reliable enough either. If we have the tens of unresoved symbols fixed, using LLVM for backend codegen should be possible, and will also evolve minimum extra dependencies.

@morganbr
@Blealtan, I'm open to the idea if it simplifies setup for new developers and CI and works well enough to replace Emscripten. It does seem plausible that we'll use LLVM at some point. I haven't looked too closely at the LLVM target, but as far as I know, it's missing a few things:
I don't believe there's a binary distribution of it, so people would need to build it from source with a special flag set. I guess it might be possible for MS to build a copy and make a NuGet package or something though.
Emscripten provides an html page and JavaScript to host the WASM. This would have to be replaced by something (maybe handwritten html and JS?)
Emscripten can convert DWARF debug data to source maps. This isn't actually working for us right now, but I really hope we can start taking advantage of it soon.
Emscripten provides a fairly broad set of "system" APIs that I'm not sure whether LLVM has.
If there's a proposed way to handle all of those (and LLVM actually works with our output), then it could make sense to switch over.

@blealtan
@morganbr short replies on those points:

Yes because it's still listed in experimental targets rather than "all" (released) targets. An custom built package will be required before the LLVM team think it's mature.
Yes and I think I can help.
Not sure but LLVM itself provides rich scaffolds for doing these things, so I'm optimistic on that. Though I'm working on make it work and try it out.
AFAIK, LLVM is not responsible for implementing any "system" libraries, so if only LLVM, no. IDK if Clang or any other LLVM accompanied optional components like libc++ has did anything on this. However, accompanied with hand-written html & js, we have the opportunity to separate assemblies; that is to say, implement an assembly loader in js, port (maybe part of, at the beginning) dotnet runtime library to wasm, import the required interfaces from CoreFX wasm interface into user-built assembly (a standalone wasm instance), and that's it. "System" APIs shouldn't be directly called from user code; they're expected to be called in CoreFX, and the canonical way to do this should be import corresponding interfaces from js and implement System.* with the imported js interfaces.
I'll do some experiments on these and hold on for my update.

Also, I've tried LLVM on our output: the biggest problem is many unresolved symbols are generated. Emscripten simply ignores them and leave the risk to runtime, but LLVM seems to be doing a strict check. Do you have any idea where the unresolved symbols are from? EMCC also produces tens of warnings when generating HelloWasm.

@blealtan
@morganbr Okay and I have some results. LLVM's llc does compiles our generated code in HelloWasm.bc, with all thread_local modifiers removed (since this is not implemented in LLVM, rather than ignored as is in Emscripten) and target triple changed to wasm32-unknown-unknown-wasm according to LLVM's requirement. However, Generating libPortableRuntime has failed due to the usage of atomic instructions, which is again not implemented in LLVM instead of atomicity ignored as is in Emscripten; on this point, change the behavior in IR one by one is a time-wasting job so I didn't try to replace these instructions with non-atomic ones.
In short, generating our code with LLVM is possible, once we have our codegen fully thread-unrelated; even further, correct execution can be also expected, once we have our previously required "system" APIs by Emscripten implemented in JS and imported to our wasm instance. I think maybe the later one is the problem; not sure how many of these APIs are actually used by our code.
As to the debugging problem, source maps is generated according to !dbg directives rather than DWARF data in LLVM, and llc does great job on doing that mapping. I think providing that is acceptable, if we want debugging support one day. However, the critical point is that no explorer supports debugging wasm at this moment; this is what we should consider in the future.

Most of the unresolved symbols are probably P/Invokes from the framework into native libraries that build out of the CoreFX repository. https://github.com/dotnet/corefx/issues/26107 tracks creating a WASM build flavor for that repo.
It's possible we still have some RuntimeImports or RuntimeExports that aren't hooked up right correctly as well. I don't have the output handy, but if they start with "Rh", they're probably runtime imports or exports.

There's another problem though. If switching to LLVM backend, what will we use for native code compiling? Clang is currently capable of compiling to WASM directly either, with the corresponding target enabled; however generating debug information still needs a detour, first generate .bc then to .wasm. Anyway, if we are dropping Emscripten, we need something to do the native code compiling, which is most possibly Clang. Is shipping this over NuGet acceptable?
Also, I'm trying to switch to clang for generating our native codes and try the -mthread-model=single flag, seeing if there's nothing generated dependent on thread_local and atomicrmw. Hopefully I can bring some good news.

Okay the -mthread-mode single flag works fine but without Emscripten provided CMake platform file, CMake always try to detect wasm-only clang as a normal compiler - which is not since it cannot produce single executable - and thus produce an error on checking phase. I'll later try to write an standalone platform CMake configuration for the wasm-only clang to solve this.

Making a Clang NuGet package could be plausible, though it would certainly be easier to wait for an official build so we don't have to figure out how to build and package it for 3 OSes.

@Blealtan, to help my understanding, what do you expect that LLVM will do better (or worse) than Emscripten? Some interesting aspects to compare on could include:

Size of the generated WASM
Performance of the generated WASM (not sure if there would be any differences here since they're both using the LLVM optimizer)
Build time
Ability to distribute a working toolchain
Likelihood of implementing new WASM features as they arrive (particularly threading and exceptions)
Supportability over time (in other words, if we find bugs, will they get fixed?)
Integration into the CoreRT workflow

@morganbr Not having any extra ideas on the compare, I'll only cover what you've mentioned for now.
The first thing to point out is that Emscripten is firstly a self-implemented JS backend embedded Clang & LLVM toolchain, with WASM added later. So it will be clear that for LLVM WASM target:

Size of generated code is influenced by two factors: the level of optimization and the amount of extra code introduced. For the first part, see next para. For the latter one, LLVM's WASM target generates clean and neat WASM code without any additional content or assumption on environment; I don't know how is Emscripten performing on this, but at least it is importing large amount of functions into generated "executable", as Emscripten is pretending itself to be a Unix platform.

Level of optimization should be at least higher than Emscripten. The LLVM community has been implementing their WASM target from scratch without reusing Emscripten; in my opinion, this decision by them means they can do better (and also I think a compiler-expert community is more reliable on this than a web-expert community, which is exactly what Emscripten&WASM community was).

Build time is also related to how good the backend is implemented. As we all know, with higher level of optimization, it will turn to be longer; with better optimization on optmizer implementation, it will turn to be shorter. Assume the same level of optimization, I personally repeat my confidence on LLVM and it's community.

For distributing the toolchain to user, LLVM backend can be always referenced as a library, while emcc requires call to emcc.bat or emcc.sh, then internally to emcc.py, and so on. If using LLVM backend, we can embed the LLVM IR to WASM phase into ilc, making ilc generate wasm directly, instead of distribute CoreRT ILCompiler along with a large Emscripten SDK.

It seems LLVM is going to be the canonical platform that generates WASM code. It's mentioned on Roadmap - WebAssemly that

Next Steps
...
graduate the WebAssembly LLVM backend from experimental to stable (and update Emscripten)
...

This possibly means Emscripten will migrate to LLVM WASM target later on, since the Emscripten developers are mostly the same guys as in the WASM community and thus the WASM roadmap should be able to speak for Emscripten (in case the "big boss" both seems to be kripken).
In this case, there're reasons to believe LLVM will get consequently updated after WASM specification (which not yet exists).

LLVM the whole project itself has been actively updated for years; also for the recently started WASM target, there were 12 commits on it in the past one month. It's a large, active, open and responsive community backing LLVM, it should at least be not worse than Emscripten.

For the workflow of building CoreRT:

Environment setup would definitely get simplified, since Emscripten is simply more and larger than Clang & LLVM: it's even dependent on Java Runtime and Python. We'll be able to ship all the dependencies (a wasm-enabled customized build of Clang as compiler toolchain, and a wasm-enabled customized build of libLLVM; the first one might possibly be dependent on the later) over NuGet.
Native part building will rely on Clang, possibly allowing CMake to generate working MSBuild building system.

For the workflow of CoreRT building some code:

The ilc will be able to generate WASM directly, without requiring invoking emcc after the ilc codegen.

On every aspect there are reasons that LLVM will do better. One problem seems to be the build system: CMake does not recognizes clang on wasm, since it refuses to generate an executable during compiler test. I've been looking into how Emscripten avoided this and I've got some insights. Besides this, it will be that we don't know when will LLVM WASM target graduate from experimental state.

Interesting discussion here! Some notes and thoughts:
There are really 3 options,

Use emscripten with the asm2wasm backend.
Use emscripten with the LLVM wasm backend.
Use the LLVM wasm backend by itself, without emscripten.

About 1 vs 2, Emscripten plans to change its default from the asm2wasm backend to the LLVM wasm backend eventually. We haven't done that yet because we are still improving the LLVM wasm backend, it isn't stable yet and doesn't generate good enough code, but hopefully later this year. You can try it already though, just point emscripten to a build of LLVM with the wasm backend enabled.
About 2 vs 3, you can use the LLVM wasm backend without emscripten, but if you need some of the following things that emscripten provides, you'll need to implement them yourselves since the LLVM wasm backend can't do them:

Porting and building system libraries like libc, libc++, SDL, etc.
Support for longjmp and C++ exceptions.
Integration with web APIs like printing to the console, date/time operations, rendering to WebGL, etc.
Emulating a filesystem.

About code size and optimization, overall the LLVM wasm backend does not yet generate as good code as the asm2wasm backend. For example, on Box2D, which is pretty typical:

Emscripten with asm2wasm: 116K
Emscripten with LLVM wasm backend: 124K (7% bigger)
LLVM wasm backend by itself: 133K (15% bigger)
About half the 15% difference can be removed by running the binaryen optimizer, which is the main difference between the last 2 lines.

Regarding performance, the picture is more complicated as often the two backends' outputs run at the exact same speed. But in realistic workloads often the LLVM wasm backend is still slower, we need to do more work there (for example, 9% slower on zlib, 4% slower on bullet).
About build times, currently LLVM wasm backend build times are slower, because of limitations of LLVM's codegen (in particular, it is single-threaded, while the asm2wasm path can use multiple CPU cores for most of the work). However, this will matter a lot less when the LLVM wasm backend gets incremental compilation, which is making very good progress.
Overall, I think it's worth experimenting with the LLVM wasm backend even if it isn't better yet, as it should improve. Regarding using it with or without emscripten, that depends on if you need any of the emscripten features listed above.

Level of optimization should be at least higher than Emscripten. The LLVM community has been implementing their WASM target from scratch without reusing Emscripten; in my opinion, this decision by them means they can do better

This is a complicated topic!
I wouldn't say LLVM's wasm support is from scratch: it's built on the existing LLVM backend codegen infrastructure. That is its biggest advantage, since that codegen is incredibly powerful for generating x86 and ARM code, etc., but also its biggest downside, since it's slower to run and less good a match for WebAssembly.
By less good a match I mean that WebAssembly is quite different from x86 and ARM - for example, it has structured control flow. Things like that are the main reason the LLVM wasm backend emits larger code currently. I suspect that to really generate optimal WebAssembly it's better to work in an IR designed from scratch for it (like in the binaryen optimizer) but on the other hand perhaps with more work we can achieve similar results even in the LLVM wasm backend, even though it wasn't designed for WebAssembly. Too early to tell.

many unresolved symbols are generated. Emscripten simply ignores them and leave the risk to runtime

You can change that default by running emscripten with -s ERROR_ON_UNDEFINED_SYMBOLS=1.

Surprised that @kirpken is here! Thanks for your clarification and correction. Seems that I was betting too much on LLVM XD
The most critical problem I was considering is distributing and integrating, which sucks for Emscripten. We'll require users to have an EMSDK if using Emscripten, and a two step compilation also; which is really not so user friendly. Regarding the requirement on libc/libc++, I'm still new to this project and not able to draw actual conclusion.

I believe now would be a good time to move to LLVM 8 and the wasm backend (which is not experimental in 8) as for large programs we seem to be hitting https://github.com/emscripten-core/emscripten/issues/8393.  We need to wait for LLVMSharp to be built and packaged for LLVM 8 or do it ourselves (which I tried but so far have been unsuccessful).

There's already a task to track for LLVMSharp, https://github.com/Microsoft/LLVMSharp/issues/84

@jkotas @MichalStrehovsky  I think we can close this now.

authors: Blealtan kripken morganbr yowl


text:
Additional tests around symbol uploader package in arcade-validation

Historically updating Sybmol uploader task has caused a bit of errors in repos like runtime, installer etc.
We should write some tests around it in arcade validation so that we don't have to test them against product repo everytime there is a change to this package.

Release Note Category

[ ] Feature changes/additions
[ ] Bug fixes
[ ] Internal Infrastructure Improvements

Release Note Description

@epananth can you please elaborate on what kind of validation is missing here and what kind of tests you would like added?

Adding @hoyosjs
He has more info on this

Closing, it's been a while and we don't know what we want to validate. Feel free to reopen once there are concrete scenarios to look at.

authors: epananth riarenas

repo: dotnet/dnceng


text:
The system image could not be created

I am in China, due to the Google service cannot be accessed, result in unable to download the images.  hope  this page is able to increase the mirror node

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 779d2db3-3e9c-2692-57ff-787d9465a444
Version Independent ID: e77ba6a7-e59d-1e1e-52e1-935f98a985cf
Content: Build your first .NET MAUI app - .NET MAUI
Content Source: docs/get-started/first-app.md
Product: dotnet-mobile
Technology: dotnet-maui
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @msglog
Apologies for the delayed response. Afraid that there's not much we can do about this. The emulators are hosted by Google and there's nothing we can do to provide access to them in China.

Hi @msglog
Apologies for the delayed response. Afraid that there's not much we can do about this. The emulators are hosted by Google and there's nothing we can do to provide access to them in China.

Would you like to consider adding the feature of "Custom Simulator Download Address" to this feature?
idea：

Set custom download address?

Manually customizing the actual execution path and image of the simulator?

If 'custom download address' or' custom execution path or image 'is not supported.
this feature will not work properly in regions that do not support accessing Google services

authors: davidbritch msglog

repo: dotnet/docs-maui


text:
Missing info about flag that controls WPF's Dispatcher Culture behavior

I was debugging an issues we had in WPF project after migrating from 4.5 to 4.8 that resulted in application language switching not working correctly. During the debugging, CurrentCulture and CurrentUICulture on System.Threading.CurrentThread were constantly switching back and forth between the new language and the old one.
After debugging discovered there's a flag Switch.MS.Internal.DoNotUseCulturePreservingDispatcherOperations that reverts back the behavior to the old one, but couldn't find it documented in the docs. I only found some mentioned of it in PRs, issues and in code. It would be nice to have it documented so that other doesn't have to the debugging.
Finally we had to also set the flag NoAsyncCurrentCulture which is mentioned in this doc so I'm wondering why the other one is not. Is there any reason this flag is not documented?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 00272f16-e267-e444-e4f1-c2c07621b1e1
Version Independent ID: 8229efac-393f-b9bc-d458-60ececc63cd0
Content: Retargeting Changes for Migration from .NET Framework 4.5.2 to 4.6
Content Source: docs/framework/migration-guide/retargeting/4.5.2-4.6.md
Product: dotnet-framework
Technology: dotnet-appcompat
GitHub Login: @chlowell
Microsoft Alias: gewarren

We had to enable BOTH options to be able to fetch user language preferences at runtime before "Show"-ing the first window.
As the fetching occurs asynchronously the dispatcher and Tasks always overrode the CultureInfo settings back to the "default".
But WPF required us to properly set CultureInfo.CurrentUICulture as binding otherwise used wrong resources (x:Static SomeResource.Text or ToString()-based bindings)

authors: kirides pawlos

repo: dotnet/docs


text:
Missing external aliases

This doc is missing Namespace alias qualifiers.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7569e51d-92c7-294a-2d5f-e1ab3c35fdf8
Version Independent ID: 86a1c11a-1d3c-902b-6cf3-5c004c59a856
Content: using directive - C# Reference
Content Source: docs/csharp/language-reference/keywords/using-directive.md
Product: dotnet-csharp
Technology: csharp-language-reference
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

It's not.


text:
SEO for related, but not necessarily exact terms

I had an interesting discussion with a member of the F# Software Foundation who was looking to get started with F# on .NET Core using a mac.  He typed the following into google:

"fsharp dotnet core"
"fsharp dotnet core new project"
"fsharp macos"

What he was ultimately looking for was this article: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/get-started-command-line
The article contains the following relevant things:

" This article covers how you can get started with using F# on .NET Core."
" To begin, you must install the .NET Core SDK 1.0 or later. There is no need to uninstall a previous version of the .NET Core SDK, as it supports side-by-side installations."
Mention of the dotnet commands, with examples, and "F#"
"Starting with .NET Core 2.0, you don't have to run dotnet restore because it's run implicitly by all commands, such as dotnet build and dotnet run, that require a restore to occur. It's still a valid command in certain scenarios where doing an explicit restore makes sense, such as continuous integration builds in Visual Studio Team Services or in build systems that need to explicitly control the time at which the restore occurs."

And yet, this article was not in his Google search results.  I'm no expert in SEO, but I believe this article does a pretty good job about being discoverable.  What could be improved?  And what does this imply about other articles in the docs?

For SEO, the most important things are file name, title, H1 and the first paragraph (1 or 2 sentences).
But I see the article in the search results for this one:
https://www.google.com/search?q=fsharp+dotnet+core+new+project - ranking 4
For fsharp macos, the page doesn't have any reference to macos, so it would be hard to be picked up by search engines. Maybe try adding the OS keywords in the introduction or title?

@mairaw Would that also have something to do with you having viewed that article in the past? When I search in incognito mode, it's not on the front page.

it's number #8 for me in incognito.

authors: cartermp mairaw


text:
Revised the sections about C# numeric literals

Renamed literals to "integer" and "real" to match the spec.
Mentioned u, U and all possible ulong suffixes for integer literals
Combined "Literal suffixes" and "Type of a literal" sections about integer literals, as those two sections talk about the same.
Added examples of the scientific notation (1.2e-3) for real literals: Fixes #7782

@BillWagner I'll do that in my next PR.


text:
Fix typo in unit-testing-with-dotnet-test.md

Fixed a typo in the name of a directory in the tutorial.
Details
I have fixed a typo in the name of the directory we have to create to follow the tutorial.
In latter steps the directory is named "PrimeService.Tests", not "PrimeServices.Tests".

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@thrundi @mairaw This also occurs in docs/core/testing/unit-testing-with-mstest.md (Line 46 I think) because that topic has the same text as this one. @thrundi, do you want to squeeze a 2nd commit on this PR before the merge to fix that one? If not, no worries ... I'll pick it up a new PR this evening.

@GuardRex @mairaw  I have fixed the typo @GuardRex has mentioned.
Should I squash the commits and force push it on the branch or just leave it as two separate commits?

Thanks for the catch @GuardRex and @thrundi for making the additional fix. You can leave them separate. We can squash them when we merge.

@thrundi Yes ... thanks from me, too. I missed it on the last revision. I'm glad u caught it. :sweat_smile:

authors: GuardRex dnfclas mairaw thrundi


text:
small improvement to the readability of the Local Transactions topic

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

authors: dnfclas joellyons


text:
Edit pass on metrics /3

Edit pass

Internal previews

📄 File
🔗 Preview link

docs/core/diagnostics/built-in-metrics-system-net.md
System.Net Metrics

@noahfalk is this content going to regenerated by YAML so I shouldn't remove the bogus newlines? Or was that just a one time event? If it's a one time even I can remove the newlines, unless you think that generates too much review friction.

No, I had no plans to regenerate this from the YAML. Feel free to make changes to newlines.

authors: Rick-Anderson noahfalk


text:
Fix casing in named placeholder in code sample Worker.cs

Summary
This fixes invalid camelCase in the logging code sample Worker.cs in favour of PascalCase which should be used.
.NET uses the structural logging. The structural logging should use PascalCase for named placeholders. Details are explained in the CS1727 analyzer.
The updated page is inconsistent. The proper casing is used at other samples on the page, but not in Worker.cs which is very first example on the page.. This change removes the page inconsistency.
The current state is confusing for less experienced .NET developers.

@IEvangelist Any updates on this PR? It is very simple update.


text:
Add support for Asp.net triggers

Depends on https://github.com/dotnet/diagnostics/pull/2592

/azp run

repo: dotnet/dotnet-monitor


text:
Add Notebook failed with model builder error on the Consume page.

Copied form https://github.com/microsoft/VS-Notebook/issues/245
System Information (please complete the following information):
Windows OS: Windows-11-Enterprise-21H2
ML.Net Model Builder 2022: 16.13.6.2226601 (Main Build)
Microsoft Visual Studio Enterprise: 2022(17.2.0)
Notebook version: 0.3.2.2226306
Describe the bug

On which step of the process did you run into an issue:
Add Notebook on the Consume page.

To Reproduce
Steps to reproduce the behavior:

Select Create a new project from the Visual Studio start window;
Choose the C# Console App and .NET6.0 project template;
Add model builder by right click on the project;
Select any scenario;
Completed the training.
On the "Consume" page, add a notebook.
You will see the model builder error from the output window.
"The type initializer for 'Microsoft.DotNet.Interactive.Notebook.NotebookFileFormatHandler' threw an exception."

Expected behavior
You can add Notebook successfully on the Consume page.
Screenshots:

Additional context:
This issue is repro on all scenarios.
Error info:
The type initializer for 'Microsoft.DotNet.Interactive.Notebook.NotebookFileFormatHandler' threw an exception.
at Microsoft.DotNet.Interactive.Notebook.NotebookFileFormatHandler.Serialize(String fileName, NotebookDocument notebook, String newline)
at Microsoft.ML.ModelBuilder.CodeGenerator.CSharp.NotebookCSFileGenerator.GenerateCSharpCode() in //src/Microsoft.ML.ModelBuilder.CodeGenerator/CSharp/NotebookCSFileGenerator.cs:line 266
at Microsoft.ML.ModelBuilder.AutoMLService.ServiceFactory.CodeGeneratorService.d__6.MoveNext() in //src/Microsoft.ML.ModelBuilder.AutoMLService/ServiceFactory/CodeGeneratorService.cs:line 279   at StreamJsonRpc.JsonRpc.d__1431.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()
at Microsoft.ML.ModelBuilder.ToolWindows.ConsumeViewModel.d__52.MoveNext()

My best guess is something wrong with System.Text.Json,, will take a look on Monday

The bug has been fixed on the latest main branch 6.13.6.2227301 and Notebook 0.3.3.2227302.

authors: LittleLittleCloud v-Hailishi

repo: dotnet/machinelearning-modelbuilder


text:
Azure Integration

Azure Integration/MLOps

[ ] Notebook using the SDK

[ ] Model Builder using SDK
[ ] Model Builder DataSet work https://github.com/dotnet/machinelearning-modelbuilder/issues/1865
[ ] Add Azure as an environment option for all scenarios. XL
[ ] Create Docker ML.NET Azure custom curated environment file S

https://github.com/dotnet/machinelearning-modelbuilder/issues/1520

authors: JakeRadMSFT beccamc


text:
Error getting - The JSON-RPC connection with the remote party was lost before the request could complete.

Getting the error The JSON-RPC connection with the remote party was lost before the request could complete.
from model builder error window
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at StreamJsonRpc.JsonRpc.d__162.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at StreamJsonRpc.JsonRpc.d__151`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ML.ModelBuilder.ViewModels.TrainViewModel.<b__92_0>d.MoveNext()

I also encountered this issues.

I also encountered this issues when I clicked the start training button.

Good news, after updating the ML model, I successfully completed the training
https://marketplace.visualstudio.com/items?itemName=MLNET.ModelBuilder2022

i am facing this issue, i am running Microsoft Visual Studio Professional 2022 (64-bit) - Version 17.11.5 and my ML.NET Model Builder version is 17.18.4.2425601
Also, i noticed that, error comes only when i try to train image classification model using GPU, when i train using CPU this error is not coming and training completed successfully.

authors: ICCCCOM hscodesolution sankasumadura


text:
BUILD Error NETSDK1147 on Apple M1

Hello I get the following errors with this command
dotnet build HelloMaui -t:Run -f net6.0-ios
Error:
/usr/local/share/dotnet/sdk/6.0.100-preview.2.21155.3/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.ImportWorkloads.targets(24,5): error NETSDK1147: Die folgenden Workloadpakete wurden nicht installiert: Microsoft.Android.Sdk [/Users//Downloads/net6-mobile-samples-main/HelloMaui/HelloMaui.csproj]
Installed:
SDK 6.0.100-preview.2 (Arm64)
macOS: Microsoft.NET.Workload.Android-11.0.200.148.pkg
macOS: Microsoft.iOS.Bundle.14.4.100-ci.main.1192.pkg
macOS: Microsoft.MacCatalyst.Bundle.14.3.100-ci.main.337.pkg
System:
MacBook Pro 2020 (M1)
Visual Studio 2019
Xcode 12.4

You can add this line locally to get further:
https://github.com/xamarin/xamarin-android/blob/304e698966a16cf2af992b3a24cb0323f561c31c/src/Xamarin.Android.Build.Tasks/Microsoft.NET.Workload.Android/WorkloadManifest.in.json#L20
However, we still have some native libraries that aren't built for M1, so you'll still hit further issues.

Ok, thank you first that didn't help, then we'll wait as soon as it works

Related:

https://github.com/xamarin/LibZipSharp/pull/84
https://github.com/mono/mono.posix

The two files we need for M1 are libzip.dylib and libMonoPosixHelper.dylib.

@jonathanpeppers I faced the same issue but for macos:
/usr/local/share/dotnet/sdk/6.0.100-preview.2.21155.3/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.ImportWorkloads.targets(24,5) : error NETSDK1147: The following workload packs were not installed: Microsoft.macOS.Sdk
Unable to create package spec for project.
I installed .net6 preview 4 and maui-check formerly without add maui-check to pathvariable so I could not find maui-check command available for me, then tried to "dotnet tool uninstall -g Redth.Net.Maui.Check" not working,
"dotnet tool update -g Redth.Net.Maui.Check" also not working.
So I removed .net preview 4 and re-install .net6 preview 2 instead, however I got the above exception when load any MacOS Native app.

Fixed by install workload for macos:
sudo dotnet workload install microsoft-macos-sdk-full --skip-manifest-update
reference:
https://github.com/dotnet/maui-samples#dotnet-workload-install-command
sudo dotnet workload install microsoft-macos-sdk-full --skip-manifest-update

authors: HausBJB jonathanpeppers lihuiniu


text:
Udpate COMServer sample to show loading in default ALC

Summary
The ability to specify loading a COM component in the default ALC was added in .NET 8. Update the COMServer sample to conditionally use the configuration option that enables it.
cc @AaronRobinsonMSFT @vitek-karas

Markdownlint errors are pre-existing - all in orleans/.

repo: dotnet/samples


text:
Provide documentation & helpers to use Owin correctly with ASP.NET Core

Moved from: https://github.com/dotnet/aspnetcore/issues/39943
ASP.NET Core's current owin documentation does not details on adding the glue code to plug in things like logging, data protection, hosting shutdown tokens etc. For instance, https://www.codeproject.com/Articles/1122162/Implement-Owin-Pipeline-using-Asp-net-Core has a section about configuring the OnAppDisposing token using IApplicationLifetime.ApplicationStopping.
This glue code is required to robustly run a existing Katana-based app on ASP.NET Core. This issue tracks this work.

Potential duplicate #2

authors: Tratcher twsouthwick

repo: dotnet/systemweb-adapters


text:
/101-linq-samples/docs/restrictions.md does not execute normally, I get a red stripe every time I try

This code does not execute normally, I get a red stripe every time I try

I have the same issue. Did you figure out the solution? Thanks.

I was able to get this working with the SDK 3.1.424 installed alongside of 6.0.402.  Had to add a global.json at the root of try-samples like this
{   "sdk": {     "version": "3.1.424"   } }
Removed references to the package 'System.CommandLine.Experimental' from all of the .csproj files.
Removed the same references in .\try-samples\101-linq-samples\src\obj\project.assets.json
The first run will give an error but subsequent runs ran without issue.

I was able to get this working with the SDK 3.1.424 installed alongside of 6.0.402. Had to add a global.json at the root of try-samples like this { "sdk": { "version": "3.1.424" } }
Removed references to the package 'System.CommandLine.Experimental' from all of the .csproj files. Removed the same references in .\try-samples\101-linq-samples\src\obj\project.assets.json Be sure to update any references to the latest SDK to refer to the 3.1.424, ie: in the project.assets.json... "runtimeIdentifierGraphPath": "C:\\Program Files\\dotnet\\sdk\\3.1.424\\RuntimeIdentifierGraph.json"
The first run will give an error but subsequent runs ran without issue.

Hey man, if you managed to solve the issue, is there a way you could upload the working file somewhere? I'd do the modifications myself, but I only really now some C# and SQL, I found this repository through a tutorial but I can't make it work, so I was just wondering if you could help since you've already found a solution.

Hey TallGuy,
The version of .NET SDK you have installed is important.  I forked the original dotnet/try-samples repo to here and made the changes for you.  For this to work, you still will need to download the latest version of the .Net 3.1.426 SDK located here, afterward, if you haven't done so already, install the dotnet-try tool (same instructions on the README as before).  Then when you git clone the repo, you should be able to start a console session in the folder you save it to and run dotnet try.  It will open your browser as before but should give you sample output this time.

Thanks man, really appreciate it. Cheers!

I met the similar thing in my Computer too, the issue is solved with below steps:
The enviornment:
OS: Win 11
.NET SDKs: .NET Core 3.0 SDK, .NET Core 3.1 SDK, .NET 6.0 SDK, .NET 8.0 SDK installed.
1.Make sure you installed lastest version of "dotnet try" tool.
If you install it with the command "dotnet tool install -g dotnet-try", you need unistall it first with:
dotnet tool uninstall -g dotnet-try

If you install it with the command "dotnet tool install -g Microsoft.dotnet-try", you need unistall it first with:
dotnet tool uninstall -g Microsoft.dotnet-try

Then install the latest verion of "dotnet try" with below command:
dotnet tool install -g --add-source "https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" Microsoft.dotnet-try

In Windows, recommand to run above commands in "cmd" with admin permission.
2.Make sure you installed .NET 3.0 and .NET 3.1 SDKs
You can run below command to check:
dotnet --list-sdks

If you did not install them, download from below links and install them.
https://dotnet.microsoft.com/en-us/download/dotnet/3.0
https://dotnet.microsoft.com/en-us/download/dotnet/3.1
Note: .NET core 3.1 SDK's version is "3.1.416" so far.
3.Clone code with below command using git shell
git clone https://github.com/dotnet/try-samples

4.Create global.json at the root of the folder "try-samples":
The content is below:
{
  "sdk": {
    "version": "3.1.416"
  }
}

Note: the version "3.1.416" here should be the same as in step 2.
5.Try to compile it with "dotnet try verify" command
cd try-samples/
dotnet try verify

If no exceptions happened, jump to next step below.
Else try to remove references to the package 'System.CommandLine.Experimental' from all of the .csproj files.
6.Run "dotnet try" command to open the web in browser:
dotnet try ".\101-linq-samples"

7.Try the examples from Web.
May it be helpful for you.

References:
https://github.com/dotnet/try/blob/main/DotNetTryLocal.md
https://github.com/dotnet/try/issues/938#issuecomment-1023604536
This anwer first publish in:
https://stackoverflow.com/a/78534041/6075331

authors: ShijunJ The-TallGuy c-dev256 edmondtchoua yanglr

repo: dotnet/try-samples


text:
References Code Lens > Setting doesn't affect Code Lens

Type: Bug
The setting does'nt affect the code lens.
The references keep visible, even though the setting is deactivated.
Extension version: 2.0.320
VS Code version: Code 1.81.0 (6445d93c81ebe42c4cbd7a60712e0b17d9463e97, 2023-08-02T12:37:13.485Z)
OS version: Windows_NT x64 10.0.19045
Modes:

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
py29gd2263cf:30792227
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
vscccc:30803845
282f8724:30602487
89544117:30613380
a9j8j154:30646983
showlangstatbar:30737416
vsctsb:30748421
a2ce3375:30757347
57b77579:30736110
pythonfmttext:30731395
pythoncmvfstrcf:30756944
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
gsofb:30804716
pythonnosmt12:30797651
pythonidxpt:30805730
pythonnoceb:30805159
e537b577:30795824
dsvsc013:30795093
dsvsc014:30804076

Dupe of https://github.com/dotnet/vscode-csharp/issues/5809

authors: BerndBroos dibarbet

repo: dotnet/vscode-csharp


text:
Blazor Web App not working upon creation

Problem encountered on https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/run
Operating System: windows
I'm on Windows 11. I'm getting several errors upon creating and running my first Blazor Web app

I'm not sure why this is happening. Even the style sheet seems to be messed up according to one of the errors. As a result, I get a page that looks like this:

Hi @L-Torres-Dev! There's a known issue with spaces in project names.
https://github.com/dotnet/aspnetcore/issues/52519
Try recreating your project without spaces in the project name and see if that works.
I apologize for the inconvenience. Let me know if that works, ok?

Hello @mairaw this seemed to work! Thank you so much!

authors: L-Torres-Dev mairaw

repo: dotnet/website-feedback


text:
IsDisabled property is not working for the CardUpload component

as title

@dsdruby hi, this issue is not repro. please provide a simple repro code for me.

authors: ArgoZhang dsdruby

repo: dotnetcore/BootstrapBlazor


text:
修订DOC-03-10 Dependency Injection 依赖注入一审明显错误

@liuhaoyang #103
依赖注入一审明显错误

已修正 #169

repo: dotnetcore/aspnetcore-doc-cn


text:
🛑 Be-terna is down

In 2198d57, Be-terna (https://www.be-terna.com/) was down:

HTTP code: 404
Response time: 710 ms

Resolved: Be-terna is back up in 102fcb2 after 13 minutes.

repo: dotsi/bitamiuptime


text:
Update recipes for patch 3.5.

Patch 3.5 just came out. I'm not seeing much in terms of significant stuff in the recipes, but update whenever you get to it, I guess.

Thanks for the reminder. I've started scraping the recipes from lodestone and will update when its done.

Done.

authors: Diskmaster doxxx

repo: doxxx/ffxiv-craft-opt-web

license: Zlib


text:
Fix parsing of GraphQL Interfaces

Write test cases and implement support for interfaces. The basic functionality should work already, but some fields are only reachable by using ... on  syntax.
Documentation on interfaces:

https://www.apollographql.com/docs/apollo-server/schema/unions-interfaces/#querying-an-interface
https://graphql.org/learn/schema/#interfaces
https://dgraph.io/blog/post/unions-interfaces/

GQLSpection has implemented support for generating queries from a schema with interfaces. However, right now interfaces get parsed incorrectly in the editor tab:
query GetSearchResults {
  search(contains: "Shakespeare") {
    __typename
    ...
    on
    Book {
      title
    }
    ...
    on
    Author {
      name
    }
  }
}

I completely rewrote the request parser, it should fix this.

repo: doyensec/GQLSpection


text:
Testing

Motivation and Context

JIRA issue: https://digital-engagement.atlassian.net/browse/SDPA-
Changed

Screenshots

How Has This Been Tested?

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Improvement/refactoring (non-breaking change that doesn't add any features but makes things better)

Checklist

[ ] I've added relevant changes to the documentation.
[ ] I have added tests to cover my changes (if not applicable, please state why)
[ ] My change requires a template update for create-ripple-app.
[ ] I have added template update script for next release.

@tim-yao is this still needed? Will close otherwise

@tim-yao is this still needed? Will close otherwise

Yes, closed. cheers!

authors: dylankelly tim-yao

repo: dpc-sdp/ripple


text:
🛑 Main Website Service is down

In 7cc5e19, Main Website Service (https://dpG06.top) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Main Website Service is back up in 57a8b9e after 5 days, 22 hours, 38 minutes.

repo: dplayz/status


text:
fix: support folders with spaces in npm

Closes #33.
This fixes the problem with local node_modules, but I wonder if the quotes should be added at a higher level, for example, when populating cmdPath or if it is ok to do it only on node_modules.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Haha, no problem. Glad to help 🙂

authors: CLAassistant luisherranz

repo: dprint/dprint-vscode


text:
CUDA error - not sure of solution

Dear Unidock developers,
Thanks for producing this software for us to use!
I really appreciate that.
We've run into some errors when I start to use multiple ligands as input parameters.:

"....
.....
Computing Vina
grid ... done.
Total ligands: 283
Batch 1 size: 283
> CUDA error at /apps/chpc/bio/Uni-Dock/unidock/src/cuda/precalculate.cu:198
code=34(cudaErrorStubLibrary) "cudaMalloc(&atom_
xs_gpu, thread * max_atom_num * sizeof(sz))"

Do you know what is happening?
By the way, I think we have Nvidia V100 x 16GB cards,
will this cause an issue? I saw in your code that you recognize the 32GB V100 when you determine the memory size to be allocated. Is this part of the problem?
Regards
Jeremy

Hi Jeremy @JGBurgess1 ,
I noticed that you are facing the error of code=34(cudaErrorStubLibrary). This indicates that your CUDA library or driver is not installed correctly. Run nvidia-smi to check if the system can use GPU.
V100 16GB should work. Please let us know if you encountered CUDA out-of-memory errors.

I ran nvidia-smi, on the GPU node.
Wed Nov  1 21:03:05 2023
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 520.61.05    Driver Version: 520.61.05    CUDA Version: 11.8     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Tesla V100-PCIE...  Off  | 00000000:3B:00.0 Off |                  Off |
| N/A   32C    P0    34W / 250W |      0MiB / 16384MiB |      1%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  Tesla V100-PCIE...  Off  | 00000000:AF:00.0 Off |                  Off |
| N/A   53C    P0   191W / 250W |   1392MiB / 16384MiB |     99%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   2  Tesla V100-PCIE...  Off  | 00000000:D8:00.0 Off |                  Off |
| N/A   45C    P0   119W / 250W |    378MiB / 16384MiB |     72%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    1   N/A  N/A    340553      C   ...u/amber/18/bin/pmemd.cuda     1388MiB |
|    2   N/A  N/A    325488      C   ...pu/gromacs/2020.1/bin/gmx      374MiB |
+-----------------------------------------------------------------------------+

What does this mean? Regards, J

@JGBurgess1
I guess you are using a cluster with slurm/PBS? Please try compiling and running Uni-Dock on the GPU nodes.

repo: dptech-corp/Uni-Dock


text:
A small shift of the center position

Very useful tools!
I found there is a small shift of the center position between the image I get from unagi (upper) and from hsc_map directly (lower):

They are fed with the same coordinate and the real size of the image is the same (3.6" x 3.6"). What could be a possible reason for this?
Thanks!

Not sure what happened at that time, it is fixed in the current version.

repo: dr-guangtou/unagi


text:
Obsidian Theme

Is says that the Dracula theme is a legacy theme
Obsidian version: 1.6.2
Windows 11 Pro

That's a different theme.
This repo is for the "Dracula Official" Theme

authors: Chrismettal salvoza

repo: dracula/obsidian