I am making a new biztalk solution, where i am using existing maps, schemas and orchestrations. And the orchestrations is giving me lots of problems.
I get this erorr message when I try to build my orchestration:
a 'module' must have a non-null XmlNamespace under BPEL4WS compliance
I can't find any solution to it anywhere, so I hope somebody can help me here.
What does that error mean and how do I solve it??
It turned out that if I clicked on the Project name, there is a BPEL Compliance that was set to True. Should have been set to false.
This doesn't look familiar at all.
Right click on the project and hit properties. Check to see if your assembly namespace and name are set in the 'Application' tab.
Open the orchestration and click on the background between the port surfaces. Check the namespace in the properties window.
If that doesn't work perhaps you can temporarily remove items from the orchestration to see if you can isolate which shape is causing the error.
I have had very strange issues where the orchestration namespace was incorrect.
Some projects require the BPEL Compliance setting to be true. For those projects you may have two cases:
If you do not wish to export the orchestration as a module; make sure the Module Exportable setting is false.
If you wish to export the orchestration as a module; make sure the Module Exportable setting is true together with a Module XML Target Namespace setting that has a valid value instead of being empty (or null)
Related
I have a customized Account "Main" Form in CRM.
I added a new tab, a new section, and new fields inside it.
I published all customizations before-hand, then export, then import into my test environment. I publish all in the test environment.
The Unmanaged Solution contains this form and its new fields; When I review the Form XML in the exported zip's customizations.xml file, it indeed has the new tab label, new section label, I can see the fields in the XML.
PROBLEM: But after importing and publishing into the test environment... the changes don't show up!
What I see in its place is the way that section looked BEFORE (not sure how long ago last time it was changed). It's simply not getting my latest changes.
How can an Unmanaged solution import have these issues? What else is there to check/consider? I don't think Solution Layers would cause this since it's Unmanaged, nothing stood out there anyway.
Please follow this check list, also note* with Dynamics it needs more env/info including your environment to trouble shoot, since it could be something in tandem with your env.
1. Usual Suspects in an UnManaged Solution
With yours being an UNMANAGED solution, I strongly suspect its a security permissions issue not setup/enabled in the Target environment, check your logs, you may see something like this
Try these Solution Importing steps
Import your main solution (note* without field security profiles).
Now, Publish all your customizations (note* you can enable/import the field security after this step)
Lastly, Import the second solution which would contain your field security profiles
2. Troubleshooting Checklist
To resolve/hunt down the issue, try these checklist steps
Check IIS: if you reset/restart IIS, (after define and publish your field)
Clear you client side cache: run it by
pressing Ctrl+F5
Clear you server side cache:
https://learn.microsoft.com/en-us/powerapps/maker/portals/admin/clear-server-side-cache
Are using the entity form:
Do you have the correct: entity permissions Notes & Sub Grid
https://learn.microsoft.com/en-us/powerapps/maker/portals/configure-notes
Did you add the metadata
Lastly are you using activities
I was looking for a configuration parser for go and https://github.com/spf13/viper seems to come highly recommended.
I am very surprised to find that configuration files are not validated by default.
Viper parses files and extracts requested values from them but I cannot find a way to detect bad configuration.
For instance I if create a (Java style) .properties file containing just "???" and nothing else. This is accepted without any error.
I can understand the philosophy that you should ignore irrelevant configuration items but I desire more rigor. I would also like to reject anything that does not match the X=Y format in a properties file.
To me this is a fatal flaw that suggests I should use a different package (or roll my own as usual).
Have I missed something? Does viper in fact support detecting and rejecting bad configuration keys?
I think the answer is no. viper does not validate java .properties files.
I posted a bug report (or feature request depending on your point of view) as https://github.com/spf13/viper/issues/790
You can try https://github.com/num30/config library which is based on Viper. It has built-in validation.
Following error shown in the problem section for unknown property
There is no easy way to fix the warning in STS4
Even after adding the quickfix, the error is not seems to be going
Description Resource Path Location Type
'IntuitAccountingAPIHost' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 8 org.eclipse.lsp4e.diagnostic
'OAuth2AppClientId' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 2 org.eclipse.lsp4e.diagnostic
'OAuth2AppClientSecret' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 3 org.eclipse.lsp4e.diagnostic
'OAuth2AppRedirectUri' is an unknown property. application.properties /hk-qbo-connector/src/main/resources line 5 org.eclipse.lsp4e.diagnostic
You should probably consider raising your problem as a bug-report or feature request on our issue tracker. It doesn't read like a 'question' to me, and so it probably doesn't belong on SO as such.
Nevertheless let me try and answer as best as I can.
Even after adding the quickfix, the error is not seems to be going
It will, once you save the additional-spring-configuration-metadata.json file where the quickfix creates new metadata for you.
I agree it is a little unintuitve that the change is not saved automatically, but I'm afraid we (STS vscode extension) don't have control over this. The changes are being applied by the Vscode language server client, and it's the client's decision to apply the changes only to 'dirty' editor buffers rather than apply them directly to the files on disk.
As to your general statement that 'In STS 4.0 ignoring unknown property support is missing'... I think you are referring to the fact that in STS3 it used to be possible to ignore problems of a given type altogether and this is no longer possible in STS4. This is true. If you like to get this kind of user-configurability back again, please consider raising a feature request on our issue tracker. SO, really isn't the place to ask for this sort of thing.
In STS 4.11, you will find this option in Window -> Preferences -> Language Servers -> Spring Language Servers -> Spring Boot Language Servers -> Yaml Editor or Properties Editor.
I've tried to compile .NET project and this CA appears, however I can't find any information about it on MSDN, do you know how to fix it?
The documentation can be found here:
https://msdn.microsoft.com/en-us/library/dn621098.aspx
Rule Description
To use security critical types, the code that references the type must be either security critical or security safe critical. This is true even if the reference is indirect. For example, when you reference a transparent field that has a critical type, your code must be either security critical or security safe. Therefore, having a security transparent or security safe critical field is misleading because transparent code will still be unable to access the field.
How to Fix Violations
To fix a violation of this rule, mark the field with the SecurityCriticalAttribute attribute, or make the type that is referenced by the field with security transparent or safe critical.
In the Error List you can click the underlines CA2151 link or right click the line and select Show Error Help. Both actions will launch the MSDN overview of code analysis violations. From here you can find a link to the description of CA2151 and how to fix it.
I'm probably not the first one facing this problem, but I couldn't find a proper answer anywhere.
I have a Windows Forms application that uses a strongly-typed DataSet. The designer uses a connection string defined in the application settings. The trouble is that this setting is defined as Application scope (thus read-only), and I need to be able to change it at runtime. In the settings designer, when the type of a setting is "Connection String", it's not possible to change the scope to "User". And the generated dataset doesn't provide a constructor allowing to choose the connection string at runtime, it always uses the one in the settings.
Do you know why MS introduced this restriction? Do you have any workaround?
I'm currently using a workaround that's really ugly: I change the type of the setting to "String", and the scope to "User". That way, I can change it at runtime and it works fine. The trouble is that when I need to modify the dataset in the designer, I have to change it back to "ConnectionString", otherwise the designer doesn't work.
Thanks in advance for your suggestions!
You can change the value of an ApplicationScope setting at runtime. While the generated and strong-typed property is readonly you can use:
Properties.Settings.Default["App1"] = "bbb";
After that, Properties.Settings.Default.App1 will read "bbb";
This should make it possible to leave the design time setting alone.
You cannot use Settings.Default.Save() for ApplicationScope settings but that is intentional. A normal User does not have the privileges to write in a subfolder of Program Files