Is it possible to make a WCF reference in a Silverlight DLL private? The option is greyed out and when you edit the Reference.vb file manaully, when running, it complains about not being able to serialize because it is not public.
I don't want the service to be exposed outside of the DLL. Is this possible?
Even though it is generated, you can hack that file up as much as you like, within reason.
What you need to do is declare your generated proxy as internal. You can either do that manually, or you can use the /internal (short form is /i) flag when using svcutil to generate your proxy. (Note that VS doesn't use svcutil when you add a service reference).
Related
There is ServiceReferences.ClientConfig file that holds different settings of WCF services Silverlight application is using. Nice and easy, except once you set them you cannot change them later without modifying a xap.
I want to make these setting configurable with a less pain.
There are several options:
Add a dedicated section in web.config where an administrator could change them. Transfer these settings to silverlight then rendering object on page. Parse it in silverlight, then build channel manually. Something I'd rather avoid.
It would be nice if we could say silverlight application to load ServiceReferences.ClientConfig not from xap resources, but from a specified uri. That way I could place this config along web.config. Nice. Not possible though.
If I could substitute resource stream resolver, that would work too. Sadly it doesn't seem to be possible either. There is IApplicationResourceStreamResolver, but it's internal.
Maybe there is a way to rewrite application resource stream after a silverlight application is started?
I guess you want to make the servicesclient config file at the runtime.
If that is the case then simply create object of System.ServiceModel.BasicHttpBinding and assign properties and assign service URL to System.ServiceModel.EndpointAddress. This binding object and endpointaddress object can be then assigned to the client object constructor and voila!
I have wcf client. It uses .NET 3.5.
When I compile the client I get two files:
client.exe and
client.exe.config.
The second file contains configuration for the wcf client.
In my case I need to prevent the user sitting on the computer to see the urls and change some other parameters from the config file.
So the requirements are, the end user not to see and modify the data stored in the config. The config file contains the same data as app.config. I need to forbid the person using the program to see the end point urls so easy.
Also I have a lot of configuration there so I do not like to code in the moment.
Is there any solution for the problem (embedded app.config of something else)?
Edit: I do not need configurable options. The config file is automatically created when adding service reference from the studio.
Regards
You can also create your proxies programatically instead of using the service reference feature.
Every parameter in the serviceModel config section can be represented in code as well.
The ChannelFactory class will help you create proxies to the service.
You can easily encrypt entire parts of your config files - and not just web.config in web scenarios, but also application config's in stand-alone apps.
Check out some resources on how to do this:
Encrypting web.config values
Encrypting passwords in .NET app.config file
Encrypting the app.config file for Winforms application
when adding a service reference an app.config is generated. What I'd like to know is, do the bindings, endpoints and everything else reflect the service, that I created the reference to? Do they specifically define that services bindings, security type,..etc, or is it simply a generic app.config? There seem to be a lot of settings..
Yes, the amount of stuff the Add Service Reference wizard dumps in your app.config/web.config is staggering - and largely unnecessary (because it basically puts in all the settings, even all of those that are default values).
Yes, the settings include thing like
binding and binding configuration (parameters like timeouts, proxies etc.)
behaviors (client-side)
client endpoint(s)
If you're interested in learning how to manually create those configs to the bare minimum (which is very easy to do, very easy to understand, too!), watch these videos:
DotNet Rocks TV Show #122: Miguel Castro on Extreme WCF
DotNet Rocks TV Show #135: Keith Elder Demystifies WCF
Both show how easy it is to create manual configs and how little you really need to supply! Highly recommended.
The settings do pertain to the service reference you just created. At least sometimes, the app.config is not useful in itself. For instance, if you are consuming services from a web application, the information in app.config needs to be copied to the appropriate section of web.config to be used.
If the service moves to a different location, you can just change the endpoint in the configuration accordingly, and the service should work as before.
I have a .NET exe that I wrote and it has a couple properties that I made public and want to expose.
I want to shell this exe (Process.Start()) and then somehow reference this exe and get access to these public properties. These properties expose information about the running exe.
I know how to shell to the exe. And I know how to add a reference to the exe from my project that I want to use this object. But how do I get access to the properties of this running exe?
I hope I am explaining myself well.
If you do know the answer maybe you could just tell me what the standard method is to expose properties of a running exe to another application at run-time.
Thanks for any help!
It does not work that way.
The only ways to share data between processes are pipes (Process.Start() can redirect standard input, standard output, and standard error), shared memory (not available in pure managed code), the exit code, and filesystem or network communications mechanisms.
In your specific case I'd guess that named pipe is the technique you want.
Personally I've never used named pipe but I have used redirect standard input and standard output.
Have you considered exposing the objects to PowerShell so that you can call the object from PowerShell?
Expose the object:
runspace.SessionStateProxy.SetVariable("ObjectName", ObjectName)
Then a PS script could call:
$ IDLevel.ObjectName
In this object then you could have some simple "getter" methods that would return information about the exe.
I like this approach as not only can you get the info. but if you want, you can expose methods which will allow you to make changes to the object based on the info. returned.
The standard "Windows way" to do what you describe is to expose PerfMon counters and update them regularly.
Your EXE can host a WCF service. This service can expose operations (not properties) that can expose this information about the running EXE.
You can write a simple WMI.NET Provider Extension for your first App that exposes the configuration settings to WMI... then other programs can monitor and alter the settings...
WMI.NET Provider Extension Scenarios
http://msdn.microsoft.com/en-us/library/bb885141(v=vs.90).aspx
How to Expose Configuration Settings Through WMI
http://msdn.microsoft.com/en-us/library/bb404687(v=vs.90).aspx
Windows has many different providers for monitoring and managing Windows settings. You can register a new namespace for your application, then use PowerShell or System.Management.Instrumentation in another .NET application to monitor that namespace.
thanks for any assistance.
I'm creating a wcf web service for an external client.
The client is requesting a copy of the wsdl.
I currently am waiting on being able to provide the client with access to the service.
when I go to my local webserver running the service (http://localhost/Services.svc?wsdl) I am shown
the wsdl, the data provided contains the method signatures (from the .svc code behind),
but does not contain the included model objects (Customer, Order, ext).
To get those objects, I can find the references in the shown data and go to the url
For me to provide all needed information to the client, so that they have the entire wsdl
should I provide the main schema and also each of the imported schemas?
or is there any other way of accomplishing this (other then the client hitting a server)
ie: is there a way of packaging all of them within one file?
(Seems like something would be available to extract each of those files?)
If I were to give a .zip with each of the files, would that be enough?
Thanks,
Steven
WCF packages up its WSDL and XSD (XML schema to describe the data being sent around) into various pieces, as you've already noticed. Those are referenced from your main WSDL with additional href's.
Or even better: you can run the "svcutil -metadata" command on the command line against the DLL or EXE which contains your service implementation - this will create all the needed files (typically several WSDl and several XSD) in the directory where you run the svcutil command. That's usually a more reliable way than piecing together the WSDL and XSD files from the ?wsdl URL (you usually end up missing one or two files).
Marc
If you manually downloaded each and every sub-WSDL and XSD referenced, then yeah, it would work; but it's cumbersome, to say the least.
An option worth looking into would be to use Christian Weyer's WCF extensions for flattening your WSDL so that WCF generates everything in a single file, then giving that to your client.