I'm attempting to use svcutil.exe to generate -only- the service contracts (interfaces) from a set of .wsdl files. When I do this (from an http-hosted wsdl), it picks up the included schemas and generates all the code for them.
Great.
What I would REALLY like to do, however, is to use a set of classes already generated from the schema files using the xsd.exe tool (the reasons for this are not important, suffice it to say that I need to have the types in one assembly, and the service contracts in another). I was successful in generating an assembly containing all the types.
The problem occurs when I attempt to get svcutil.exe to use the types in that assembly. My command line looks something like this:
svcutil /target:code /noconfig /reference:my_types.dll http://path/to/wsdl
This works fine, but the generated code contains duplicates of all the types in the my_types.dll file. It is my understanding from the documentation for svcutil.exe that this is the exact problem that the /reference: parameter is meant to overcome. In my case, however, it is not working.
Why?
Apparently it only works for DataContract types and not XmlSerializer types.
Link
I had this problem. Something in a binary that I was referencing with /r was still being built again in the generated code. One of the objects being returned from one of the service functions was returning a datatable or some other horrid thing like that. I added a /r to the whole path to System.Data and that fixed it.
/r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.Data.dll"
Related
Probably a pretty fundamental question. When developing a single-project-solution in MSVC++ everything makes a lot of sense, every file is visible to the compiler. When moving to a multiple project solution, none of the interface elements governing project dependence seem to make sense (coming from a .net background.)
For starters it appears setting up project dependencies with that terminology seems to only imply what order the projects are compiled in. There is no more function attached to the definition and addressing objects or methods of one project from another will not work. #including the headers of the dependency doesn't seem to work either, so the dependent project cannot see the files of its dependency. Copying a link of a header from one project to another doesn't work either, where for two projects under the 'Header Files' section, the same file is referenced in both locations. Even with this header references do not work and the files are unconnected. The only way of creating a functional dependency is to add the dependency's paths to the linker/compiler search path of the dependent or worse, simply copying the files of one project to another.
Either I'm missing something or the .NET Visual Studio IDEs have succeeded at what the VC++ IDE has badly failed at.
Edit:
For the sake of asking a specific question, take the following steps for creating a solution in VC++ and I ask if the missing step(s) can be filled in:
Create empty DLL project inside new solution.
Create method in DLL project and compile.
Create new empty executable project.
Create main method in new project.
...
Have main method call function in DLL project.
Preferably fill in the missing step(s) with the most most modern/industry standard/best practice method that best maintains project modularity as intended.
From this I would expect to independently be able to extrapolate and create classes, enumerations etc. in the DLL class and access them all in the executable project, so long as I can find out how this is intended to be done.
In step 2, as per the usual C++ rules, declare the method in the header. Read up on __declspec(DllExport) since the default is that methods are internal to the DLL.
In step 5, as per the usual C++ rules, include the header. Visual C++ needs to know where the header is coming from, so you need to reference the source project. Details vary between Visual Studio versions.
In step 6, you call the method in the normal way. Since it's now declared as __declspec(DllImport), the compiler will leave it to the linker, and the linker will get it from the correct DLL.
I have a number of XSDs that are part of the enterprise definitions for several services at the client.
I would like to be able to take a single XSD and generate a DDIC structure from it (without the use of PI!)
Seeing as you can generate proxies directly from a WSDL, and this also generates structures and data elements from the XSD definitions inside the WSDL, there is obviously already ABAP code that does this.
But do you know what classes/function modules to use to achieve this? Perhaps there is a convenient utility function or class method that takes the XSD as input and generates the relevant DDIC objects?
Some background on why I need this:
Some of the services include variable sections that include a piece of XML containing the data for one of the enterprise XSD entities; I am hoping to have a DDIC representation of these, which I can fill at runtime and then convert to XML to include in the message.
There is a program on the system called SPROX_XSD2PROXY with which you can upload one or more XSD files which will generate proxy objects for you.
You also end up with a service consumer with a corresponding class and what looks like a dummy operation.
The program is fairly short; it uploads the files(s) to an XSTRING, then converts the XSD(s) to WSDL(s) and finally the WSDL(s) to proxy objects using methods of a class called CL_PROXY_TEST_UTILS.
However, the result is satisfactory as it does give me a structure I can work with. And by examining the contents of those methods, it may be possible to build a more fine-tuned tool if I need one.
I use a firefox addon which makes hidden requests to a website. I already examined the code in all .js .xul and .xpi files. there is only 1 .xpt file (1kb) left where the request must be coded. now i want to open that to examine the code too.
.xpt is afaik a compiled .idl file
Can this be done?
How?
Thanks for your wisdom ;)
An XPT file is a compiled IDL file but it doesn't contain any code - it is merely an interface definition. It defines which properties and methods a component exposes but it doesn't define them - the actual definition of the component has to be in a JavaScript or DLL file. As you aren't mentioning any binary components, the component must be defined in the JavaScript files you already looked at.
In other words: the answer to "Can it be done" is: yes, with sufficient effort. Just looking at the strings contained in the file will already tell you the interfaces defined as well as the property and method names. If you need the parameters/parameter types then you will have to dig deeper. But for your purpose that would be pointless.
After installing my files using WIX 3.5 I would like to changes some values in one of my xml files.
Currently there are multiple entries like this:
<endpoint address="net.tcp://localhost/XYZ" .../>
I would like to change the localhost to the real servername wich is available due to a property. How can I perform this replacement on each entry inside this xml file? Is there a way to do this without writing an own CA?
Thanks in advance!
XmlConfig and/or XmlFile elements are your friends here.
UPDATE: Well, according to the comments below, it turns out that only part of the attribute (or element) value should be changed. This seems not to be supported by either of two referenced elements.
I would take one of the two approaches then:
Use third-party "read XML" actions, like this one
It's better than creating your own because you can rely on deeper testing in this case
Teach your build script to control the string pattern
Let's say you put `net.tcp://localhost/XYZ` to build file and your code is pointed out to take this value as a string pattern to use at install time. For instance, keep the string pattern as a Property in your MSI package. When it changes, e.g. to `net.tcp://localhost/ABC` you'll have to change nothing in your action. In this case from a XMLFile perspective you always know your FROM and TO attribute values.
If your XML configuration file is not large, you can load the file into memory and perform replace using JScript.
var s = "<endpoint address=\"net.tcp://localhost/XYZ\" .../>";
var re = /"net.tcp:\/\/localhost\//g;
var r = s.replace(re, "\"http://newhost.com/");
Here s is your complete XML file, re is the regular expression, and r would contain the result or replace.
You can read and write to public properties of Windows Installer using JScript. Yet there's still one problem: you have to read your XML file and to write it back to disk. To do it, you can use Win32_ReadFile and Win32_WriteFile custom actions from the AppSecInc. MSI Extensions library referenced by Yan in his answer.
However, it could be easier to write a complete Custom Action which will load your XML configuration file, do the replace, and write the file back to disk. To do it you can use XSLT and JScript (see an example code).
InstallShield has a built-in data driven custom action called Text Search. It basically allows for RegEx style replacements like what you are describing.
WiX doesn't have this functionality but you could write a custom action ( say using C#/DTF ) to do it for you.
There nothing in Wix, you can do to change something in a file without using a custom action. If you don't want to use CA, you can consider saving the settings in some other place e.g. User's registry and always read that setting from there
When generating my DAL files with SubSonic, I'd like the names of the files to be .gen.cs. The main reason for this is that the files are partial classes, and I would like to add some additional implementation details into another source file for the table called .cs. This is somewhat the standard pattern for generated source files , and I'm wondering if its possible with SubSonic? I'm using SubSonic 2.2.
I thought you might be able to do this by using a set of custom templates, but the CS_ClassTemplate.aspx (or VB_ClassTemplate.aspx) doesn't control the file name of the class.
I don't think this is possible.
As an alternative, you can do what I do. I have a "generated" directory, such as \database\generated and then I put my partial classes at \database\custom. As long as the namespaces of the files in the two different directories match (like .database or whatever), then it works fine. By using two different directories, it's easier to find your custom files without looking at the generated ones.