profile
viewpoint

synesthesia/garden-pub 2

Digital Garden publisher

synesthesia/CRMDeveloperExtensions 1

Dynamics CRM 2011/2013/2015/2016 Templates & Developer Tools

synesthesia/academic-kickstart 0

Easily create a beautiful website using Academic and Hugo

synesthesia/adr-cli 0

A Windows equivalent of adr-tools (https://github.com/npryce/adr-tools)

synesthesia/adr-tools 0

Command-line tools for working with Architecture Decision Records

synesthesia/antora-lunr 0

Integration of Lunr in Antora

synesthesia/antora-site-generator-lunr 0

An Antora's site generator that produces a Lunr index

synesthesia/aspnet-connect-sample 0

This walkthrough shows you how to use the Office 365 Connected Services in Visual Studio 2017.

synesthesia/aurelia-open-id-connect-demos 0

Demos of aurelia-open-id-connect.

synesthesia/aureliatests 0

Testbed for various aureliathings

push eventdocToolchain/docToolchain

Travis

commit sha 2d80d980f9cd8485bab30aa2dbe1ef329d03a598

Travis build 599 pushed to gh-pages

view details

push time in 2 hours

push eventdocToolchain/docToolchain

Peter Stange

commit sha 2691755c46bdda84301d666d17cb784d9704b2c4

Add the export of notes found on an EA diagram itself.

view details

Ralf D. Müller

commit sha ef1febebae78fa7f56be73110751574a55caa5dc

Merge pull request #501 from PeterStange/export_diagram_notes Add the export of notes found on an EA diagram itself.

view details

push time in 3 hours

PR merged docToolchain/docToolchain

Add the export of notes found on an EA diagram itself.

This pull request fixes the issue #450. It adds the export of notes that are found for the diagram itself. Without it, all notes found on elements used by the diagram are exported only. As it requires to start the notes on elements with {adoc: to be exported, it is the same for diagram notes. If the tag is not found at the beginning of a note, the note is not going to be exported.

There was no need to update the documentation of exportEA.

I created this pull request as a representative of AndreaMcls.

+3 -0

1 comment

1 changed file

PeterStange

pr closed time in 3 hours

issue openedappveyor/ci

Support multiple build numbers for different version and branches automatically

I have read the following thread but I don't think it has the solution for my use case. https://help.appveyor.com/discussions/problems/981-different-versioning-and-deployment-per-branch The problem: I have a project with version 1.0.{build}. this is defined in the appveyor.yml file. I create a branch from that project, lets call that branch stale-feature. in this branch I don't change the appveyor.yml so it is kept as 1.0.{build}. Time passes and builds are generated and the last version of 1.0 is 1.0.100 for example. Now I move to the next version 1.1.{build} - I got to appveyor site and set next build number to be 0 so that the first version will be 1.1.0 and trigger a build so that version 1.1.0 is generated. So far so good. Now I commit a fix to stale-feature which will trigger a build. This build will fail as it will create a wrong number (one that already exists: 1.0.1).

What I would like to have is basically a mechanism that will know what was the last build number for each version and simply increment it. Moreover I would like to avoid logging into appveyor site in order to change the next build number to 0 when changing a version (major-minor). A simple checkbox saying "Automatically increment build number and set it to zero for new versions" would be ideal for me. When this checkbox is off allow the user to manually set the next build number, I guess in terms of UX... I don't know how relevant my use case is, but it feels to me relatively common in terms of versioning...

As a site note, I love your work and service, it is amazing! Keep up the good work! :-)

My current workaround is to change the version in the stale-branch to match the latest version (1.1.{build} in our case), which is not ideal...

created time in 3 hours

issue closeddocToolchain/docToolchain

ExportEA: Diagram Notes are not exported

The Diagram Objects notes are exported as expected, however the Diagram Notes are not exported.

closed time in 4 hours

AndreaMcls

issue commentdocToolchain/docToolchain

ExportEA: Diagram Notes are not exported

thank you @PeterStange for the PR

AndreaMcls

comment created time in 4 hours

PR opened docToolchain/docToolchain

Add the export of notes found on an EA diagram itself.

This pull request fixes the issue #450. It adds the export of notes that are found for the diagram itself. Without it, all notes found on elements used by the diagram are exported only. As it requires to start the notes on elements with {adoc: to be exported, it is the same for diagram notes. If the tag is not found at the beginning of a note, the note is not going to be exported.

There was no need to update the documentation of exportEA.

I created this pull request as a representative of AndreaMcls.

+3 -0

0 comment

1 changed file

pr created time in 4 hours

issue commentappveyor/ci

[QUESTION] Package artifact from two jobs in one

Yes, you can: https://www.appveyor.com/docs/job-workflows/

Example appveyor.yml where tests for Windows, Linux and macOS are run in parallel and after that there is a "releasing" job: https://github.com/pglet/pglet/blob/ui-p1/.appveyor.yml

S0PEX

comment created time in 15 hours

issue commentappveyor/ci

Show timestamps on build console

@FeodorFitsner Are there any chances this might be added as a feature to Appveyor?

MattMessmerBlossor

comment created time in 19 hours

issue commentappveyor/ci

Unable to Create New Account

I can sign up with gmail

Yannnnnnnnnnnn

comment created time in a day

issue commentappveyor/ci

[QUESTION] Package artifact from two jobs in one

Is there any way that I could keep the default build jobs and add a custom job that runs after the x64 and x86 default builds have finished ? When I tried to add a custom job to the matrix config the default jobs got disabled.

S0PEX

comment created time in 2 days

issue openedjbogard/MediatR

[Error] After upgrade to MediatR 9.0.0 : Unable to cast object of type 'System.Collections.Generic.IEnumerable'

I build a Web API with Asp.Net Core 5.0, everything working fine! But when I upgrade from MediatR version 8.0.1 to 9.0.0, I get this issue:

Error: Unable to cast object of type 'System.Collections.Generic.IEnumerable`1[MediatR.IPipelineBehavior`2[Ettip.Domain.Queries.Admin.OfficialStoryRequest.PagingStoriesByTopicsRequest,Ettip.Domain.Queries.Responses.Admin.OfficialStoriesResponse]][]' to type 'System.Collections.Generic.IEnumerable`1[MediatR.IPipelineBehavior`2[Ettip.Domain.Queries.Admin.OfficialStoryRequest.PagingStoriesByTopicsRequest,Ettip.Domain.Queries.Responses.Admin.OfficialStoriesResponse]]' - StackTrace :    at MediatR.ServiceFactoryExtensions.GetInstances[T](ServiceFactory factory)
   at MediatR.Internal.RequestHandlerWrapperImpl`2.Handle(IRequest`1 request, CancellationToken cancellationToken, ServiceFactory serviceFactory)
   at MediatR.Mediator.Send[TResponse](IRequest`1 request, CancellationToken cancellationToken)
   at Ettip.Api.Controllers.OfficialStoriesController.PagingStoriesByTopics(PagingStoriesByTopicsRequest request) in /Users/tamtang/Documents/Source Code/Ettip-Api/Ettip.Api/Controllers/OfficialStoriesController.cs:line 124
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)

After I check a lot of things from MediatR's wiki and search this issue from Google but I found nothing. Finally, I have to revert my Web API to MediatR version 8.0.1 to make my Web API working again.

Does anyone know any clues to resolve this issue?

created time in 2 days

issue openedjbogard/MediatR

send heavy task command in fire and forget mode

To avoid nested command chain I´m trying to send command sequentially

var order = await Mediator.Send(orderCommand); await Mediator.Publish(new OrderPlacedEvent(order));

// Now create contract command (heavy task) depend on order response //.. some mapper var contract = await Mediator.Send(createContractPublicCommand; await Mediator.Publish(new ContratCreatedEvent(contract));

is there some strategy to send the second command in fire and forget mode in order to response only the order as soon as possible? ...

created time in 3 days

issue commentappveyor/ci

Manual snupkg Push from Deployment Environment Not Working - "No packages were published"

Right, SymbolSource.org has been dead for a long time. Need to fix UI.

lordmilko

comment created time in 3 days

issue commentjbogard/MediatR

Notification handler causing autofac singleton class to get resolved twice

Mediator handlers are always registered as transient. They should not be coupled with singleton classes. If you need to share functionality between a singleton and the handlers a dependency of both should encapsulate that functionality

fbd-ss

comment created time in 3 days

issue commentdocToolchain/docToolchain

publishToConfluence: Error rendering macro 'code'

Thanks a lot @tkleiber This makes that error disappear. But now the json looks like this

image

Is there a way to make it look like a formatted json ?

tkleiber

comment created time in 3 days

issue commentaspnet/Announcements

Updates to Blazor client-side routing catch all and optional parameters behavior

Thanks

Thanks

Martin McSharry Integro Technologies Ltd. +44 8000 487 620 [cid:image002.png@01D6C4B5.81B81D60]

From: Javier Calvarro Nelson notifications@github.com Sent: 27 November 2020 11:56 To: aspnet/Announcements Announcements@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [EX] [aspnet/Announcements] Updates to Blazor client-side routing catch all and optional parameters behavior (#445)

Changes to routing logic in Blazor applications on 5.0.1

There was a bug in the blazor routing implementation that affected how we computed the precedence of routes. This might affect you if you have defined catch all routes or routes with optional parameters within your Blazor application.

Version introduced

5.0.1

Old behavior

With the erroneous behavior, routes with lower precedence like {*slug} would be considered and matched over routes with more precedence, like /customer/{id}.

New behavior

The current behavior more closely matches the routing behavior defined in ASP.NET Core apps, where we compute and establish the route precedence for each segment first and only use the length of the route to break ties as a second criteria.

Reason for change

The original behavior is considered a bug in the implementation since our goal is to make sure that the routing system in Blazor apps behaves in the same way as the routing system in ASP.NET Core for the subset of features supported by Blazor routing.

Recommended action

There is a new attribute PreferExactMatches on the Router that can be turned on to opt-in into the correct behavior. People upgrading from previous versions of Blazor to 5.X should take this into account.

Category

ASP.NET

Affected APIs "Not detectable via API analysis" Issue metadata

  • Issue type: breaking-change

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/aspnet/Announcements/issues/445, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AF7AXFKEMBHP3QCOA7ZISDTSR6HU3ANCNFSM4UE2DCTQ.


This e-mail and any attachments are strictly confidential and intended solely for the addressee. They may contain information, which is covered by legal, professional or other privilege. If you are not the intended addressee, you must not copy the e-mail or the attachments, or use them for any purpose or disclose their contents to any other person. To do so may be unlawful. If you have received this transmission in error, please notify us as soon as possible and delete the message and attachments from all places in your computer where they are stored. Please be aware that e-mail is not a secure form of communication. Messages sent via this medium may be subject to delays, non-delivery and unauthorised interference. Although we have scanned this e-mail and any attachments for viruses, it is your responsibility to ensure that they are actually virus free.

javiercn

comment created time in 3 days

issue openedaspnet/Announcements

Updates to Blazor client-side routing catch all and optional parameters behavior

Changes to routing logic in Blazor applications on 5.0.1

There was a bug in the blazor routing implementation that affected how we computed the precedence of routes. This might affect you if you have defined catch all routes or routes with optional parameters within your Blazor application.

Version introduced

5.0.1

Old behavior

With the erroneous behavior, routes with lower precedence like {*slug} would be considered and matched over routes with more precedence, like /customer/{id}.

New behavior

The current behavior more closely matches the routing behavior defined in ASP.NET Core apps, where we compute and establish the route precedence for each segment first and only use the length of the route to break ties as a second criteria.

Reason for change

The original behavior is considered a bug in the implementation since our goal is to make sure that the routing system in Blazor apps behaves in the same way as the routing system in ASP.NET Core for the subset of features supported by Blazor routing.

Recommended action

There is a new attribute PreferExactMatches on the Router that can be turned on to opt-in into the correct behavior. People upgrading from previous versions of Blazor to 5.X should take this into account.

Category

ASP.NET

Affected APIs

"Not detectable via API analysis"

Issue metadata

  • Issue type: breaking-change

created time in 3 days

issue commentappveyor/ci

Manual snupkg Push from Deployment Environment Not Working - "No packages were published"

The Symbol Server URL says it uses SymbolSource.org if no symbol server is specified, however I can see from your screenshots that no symbol source URL is specified and yet its somehow using nuget.org for symbols instead.

So are you saying that is in fact no longer the case that symbols will go to SymbolSource.org, or *.symbols.nupkg files will go to SymbolSource.org but *.snupkg files will go to nuget.org instead?

lordmilko

comment created time in 3 days

issue commentappveyor/ci

Manual snupkg Push from Deployment Environment Not Working - "No packages were published"

Publishing via "NuGet" environment works too:

image

Environment settings:

image

lordmilko

comment created time in 4 days

issue commentappveyor/ci

Manual snupkg Push from Deployment Environment Not Working - "No packages were published"

Hi @FeodorFitsner,

This project automatically publishes its artifacts to NuGet as part of the build process

Checking is snupkg files were created...
Deploying using NuGet provider
Publishing MySnupkgTestNetStandard.1.0.17.nupkg to https://www.nuget.org/api/v2/package...OK
Publishing MySnupkgTestNetFramework.1.0.17.nupkg to https://www.nuget.org/api/v2/package...OK
Publishing MySnupkgTestNetStandard.1.0.17.snupkg to https://www.nuget.org/api/v2/symbolpackage...OK
Publishing MySnupkgTestNetFramework.1.0.17.snupkg to https://www.nuget.org/api/v2/symbolpackage...OK
Total packages published: 4
Build success

In my scenario, I do not want to automatically publish artifacts, I want to manually publish artifacts when I am ready for release, which I do by going to the Deployments tab of my project and manually doing a deployment from an Environment I have configured for deploying to NuGet. Deploying snupkg files in this way used to work, but now it no longer seems to

lordmilko

comment created time in 4 days

issue commentappveyor/ci

[QUESTION] Package artifact from two jobs in one

Your own script doing both x64 and x86 in the same build is a good solution imho.

S0PEX

comment created time in 4 days

issue commentappveyor/ci

Manual snupkg Push from Deployment Environment Not Working - "No packages were published"

Here is test project publishing both .nuget and .snupkg files: https://ci.appveyor.com/project/appveyor-tests/snupkgtest/builds/36536075

NuGet deployment section in appveyor.yml is just:

deploy:
- provider: NuGet
  api_key:
    secure: <secure>

Hope that helps.

lordmilko

comment created time in 4 days

issue openedjbogard/MediatR

Notification handler causing autofac singleton class to get resolved twice

Hi Jimmy, Im using your MediatR and Autofac in a Xamarin project. I have a class that is registered with autofac as single instance, and it has always been resolved as a singleton, until i included a notification handler in it.

The class was defined as MyClass : IMyClass { } then with the handler it became MyClass : IMyClass, INotificationHandler<notification>{ }

from that point on it has been getting resolved twice by Autofac, once from the container and then from somewhere else, from what it seems it getting resolved again just before the handler is invoked.

I have set using the mediatR extension to scan the assemblies, ie builder.AddMediatR( typeof( xassembly ) ).

Have you come across something like this before?

Regards Steve.

created time in 4 days

issue commentdocToolchain/docToolchain

Offline build

That's useful with many ephemeral (cattle) containers, which isn't the case for us, we only have one container and our data is extracted once. And it's an incubation feature.

Anyway, I tried the --no-daemon switch and it seems to work for me in the actual scenario as resembled by the gist posted above. Now, next step is to try it on the build server and see if it works. Will do it next week, as planned.

rico-chet

comment created time in 4 days

push eventdocToolchain/docToolchain

Travis

commit sha 1f07d1b8fc0bb60fe1d6b469ed56114fe1bbe84f

Travis build 597 pushed to gh-pages

view details

push time in 4 days

pull request commentdocToolchain/docToolchain

added saveguard to not print secrets to the console

thanx for this valuable fix!

nilsmahlstaedt

comment created time in 4 days

push eventdocToolchain/docToolchain

Nils Mahlstaedt

commit sha 6d2cdce076edba019fdc6b114f581a6d452c0e8f

added saveguard to not print secrets to the console

view details

Ralf D. Müller

commit sha d2296169e022decd6e6fecc4df3e85f119e0d87d

Merge pull request #500 from nilsmahlstaedt/master added saveguard to not print secrets to the console

view details

push time in 4 days

PR merged docToolchain/docToolchain

added saveguard to not print secrets to the console

History

As discussed previously by mail a change introduced in PR #476 print all config keys and their values to the console when running with --info. This includes the Confluence and Jira Creds (Username + Password Base64-encoded). Through these changes secrets can appear in build logs unexpectedly.

Remedy

Instead of reverting the change to the config printing (i think it's usefull for debugging), this PR introduces a blacklist of config key name fragments. If a key that is to be printed contains any of the defined fragments, '********' ist printed instead of the config's value.

Details's and Considerations

This solution providing a middleground between not printing the config and exposing secrets. Though should it be merged adds a blacklist, that needs to be kept up to date when new secrets are added to the config. Currently the following fragments in the config value name (config.<NAME_1>.<NAME_2>)result in redacted output: credential, token, secret, passw, pwd. It is possible to define fragments in the form of some.name-suffix.

Feedback and comments are greatly appreciated.

All Submissions:

  • [ ] Does your PR affect the documentation? -> No
+11 -3

1 comment

1 changed file

nilsmahlstaedt

pr closed time in 4 days

more