From the “let people know when they are stupid” department:
Another reason not to pipe from curl to bash. Detecting curl | bash serverside.
Source: Detecting the use of “curl | bash” server side | Application Security
–jeroen
Posted by jpluimers on 2016/04/20
From the “let people know when they are stupid” department:
Another reason not to pipe from curl to bash. Detecting curl | bash serverside.
Source: Detecting the use of “curl | bash” server side | Application Security
–jeroen
Posted in Development, Python, Scripting, Software Development | 1 Comment »
Posted by jpluimers on 2016/04/20
I tend to forget this: xsd.exe can resolve xs:include, but not xs:import. When using xs:import it will complain about missing types.
Simple solution: reference all imported XSDs (but not included XSDs) on the same command-line:
I was trying to create a C# class with xsd.exe from an schema that imports others schemas like that xsd.exe /c schema.xsd and it fails miserably reporting an error like “The datatype ‘xxx’ is missing.”. Basically xsd.exe doesn’t resolve the schemaLocation attribute.
Dare Obasanjo’s article addresses the problem, and Scott Hanselman had the same problem -and solved it-.
The solution isn’t very nice, but at least it’s simple. You have to tell xsd.exe all the schema referenced, xsd.exe /c schema.xsd importedSchema1.xsd importedSchema2.xsd
Be aware that the C# filename is sometimes generated from all XSD filenames on the command-line (I’ve noticed this when the import is specified before the actual XSD file, if the import is at the end, the name of the import is used.
If my memory serves me right, older versions of XSD.exe could not resolve unix-style relative paths on the command-line, but newer versions do.
–jeroen
via: Support of import in xsd.exe – Jose Luis Calvo Salanova – Site Home – MSDN Blogs.
Posted in .NET, C#, Development, Software Development, XML/XSD, XSD | Leave a Comment »