Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to generate soapAction without contract name #1017

Merged
merged 1 commit into from
Feb 14, 2024

Conversation

vidrenning
Copy link
Contributor

By default, the soapAction that is generated if it is not specified in the [OperationContract(Action = "...")] attribute, follows the format {namespace}/{contractName}/{methodName}.

This seems to be different than the default soapAction that is generated in ASMX web services in .NET Framework. The new option makes it possible to omit the contractName and instead generate soapActions with the format {namespace}/{methodName}. The default for this new option is false. This means that the behavior for existing users of SoapCore does not change.

However I had to change the interface ISoapMessageProcessor to make AuthorizeOperationMessageProcessor work. The method ProcessMessage will now have an additional SoapOptions parameter. If users implement their own ISoapMessageProcessor, they have to add this parameter if they update the NuGet package. Is this acceptable?

By default, the soapAction that is generated if it is not specified in
the [OperationContract(Action = "...")] attribute, follows the format
{namespace}/{contractName}/{methodName}.

This seems to be different than the default soapAction that is
generated in ASMX web services in .NET Framework. The new option makes
it possible to omit the contractName and instead generate
soapActions with the format {namespace}/{methodName}. The default for
this new option is false. This means that the behavior for existing
users of SoapCore does not change.
@vidrenning
Copy link
Contributor Author

After thinking some more about it, I have realized that it is not necessary to change the ISoapMessageProcessor interface. I have updated the commit to reflect that. So users do not need to add a new parameter when updating the NuGet package.

@andersjonsson
Copy link
Collaborator

Great! Easier if we can avoid breaking changes :)
I'll try to take a look at the PR today

@andersjonsson andersjonsson merged commit ad81c5b into DigDes:develop Feb 14, 2024
3 checks passed
@andersjonsson
Copy link
Collaborator

Thanks!

@vidrenning
Copy link
Contributor Author

Thank you very much for merging! Sorry to bother you again with this, but would it be possible to build a new NuGet package version again? I have evaluated that no other changes are required for my situation and having a new NuGet package would mean that I can go through with the deployment 🙂.

@vidrenning vidrenning deleted the soapaction branch February 14, 2024 08:43
@vidrenning
Copy link
Contributor Author

Thank you! 🙂

@andersjonsson
Copy link
Collaborator

Thank you! 🙂

Np. Sorry that I didn't let you know about the new version immediately. A little bit too much going on at work right now and my work on SoapCore is a spare time thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants