I tried to set maxarraylength value to 5 but it does not seems to be working. From where I can get detail of this.
Is reader quotas only work server side or is it required for client configuration as well?
maxArrayLength configuration is required for client too
These attributes must be set on the client and service. Once set in
the service’s configuration file, these values will not be propagated
automatically to the client’s configuration file that is generated by
the svcutil tool or Add Service Reference in Visual Studio. You must
manually edit the generated client side configuration file and set the
appropriate values.
from http://msdn.microsoft.com/en-us/library/ms731325(v=vs.110).aspx
Related
In my Vb.net application I'm using IBM MQ v7.5 Managed client connection to connect to a queue manager. Until now I have provided channel name and host name in a .Config file and call the following:
MQQueueManager(Qmanagername, Channel, Host)
But Now I have a AMQCLCHL.TAB file with the channel details. How can I have my Vb.net application use the channel name and host name from the AMQCLCHL.TAB file.
You need to let the application know the location of the channel table file. The IBM Knowledge center shows this can be done in three ways with managed client connection type:
Using the .NET application configuration file. In the CHANNELS section, use the keys ChannelDefinitionDirectory to specify the directory where the table is located, and ChannelDefinitionFile to specify the file name.
Using the environment variables MQCHLLIB to specify the directory where the table is located, and MQCHLTAB to specify the file name of the table.
Using the client configuration file. In the CHANNELS stanza, use the attributes ChannelDefinitionDirectory to specify the directory where the table is located, and ChannelDefinitionFile to specify the file name.
You can then change your call to drop the channel and hostname and it will pickup the channel table that you specified using one of the three ways described above.
New MQQueueManager(Qmanagername)
Update to include additional information from the comments
If your application runs on the same server as the queue manager it will by default connect in unmanaged mode using server bindings if you do not force it to use client mode. This is described in detail in the Knowledge Center.
You can force it to a client mode by setting the environment variable NMQ_MQ_LIB.
For unmanaged MQ client mode use NMQ_MQ_LIB=mqic.dll
For managed client mode use NMQ_MQ_LIB=managed
The MQC.TRANSPORT_PROPERTY hashtable property can also used to force it to use client mode.
Unmanaged MQ client mode example:
Hashtable properties = new Hashtable();
properties.Add(MQC.TRANSPORT_PROPERTY, "MQC.TRANSPORT_MQSERIES_CLIENT");
return new MQQueueManager(queueManagerName, properties);
Managed MQ client mode example:
Hashtable properties = new Hashtable();
properties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED");
return new MQQueueManager(queueManagerName, properties);
I'm trying to call Apache ActiveMQ NMS Version 1.6.0 from my code ('IntPub') that must run in a sandbox in a .NET 4.0 environment for security reasons. The program that creates the sandbox makes my code 'partially trusted' and therefore 'security-transparent' which seems to mean that it can't create a ConnectionFactory (see error log below) because NMS seems to be 'security-critical'. Here's the code that's causing this error:
connecturi = new Uri("tcp://my.server.com:61616");
var connectionFactory = new ConnectionFactory(connecturi);
I also tried this instead with similar results:
connecturi = new Uri("activemq:tcp://my.server.com:61616");
var connectionFactory = NMSConnectionFactory.CreateConnectionFactory(connecturi);
Since I can't change the security level of my assembly (the sandbox prevents it) is there a way to make NMS run as 'safe-critical' so it can be called by 'security-transparent' code? Would I have to recompile it to do so, or does NMS do some operation that would never be considered 'safe-critical?
I appreciate any help or suggestions...
Assembly 'IntPub, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6fa620743b8dc60a' is partially trusted, which causes the CLR to make it entirely security transparent regardless of any transparency annotations in the assembly itself. In order to access security critical code, this assembly must be fully trusted.Detail:
<OrganizationServiceFault xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/xrm/2011/Contracts">
<ErrorCode>-2147220956</ErrorCode>
<ErrorDetails xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
<Message>Unexpected exception from plug-in (Execute): Test.Client: System.MethodAccessException: Attempt by security transparent method 'Test.Client.Execute(System.IServiceProvider)' to access security critical method 'Apache.NMS.ActiveMQ.ConnectionFactory..ctor(System.Uri)' failed.
From the error message attributes, it looks like you're running a Dynamics CRM 2011 plugin in sandbox mode, which has some very specific rules about what you can and can't do. In particular, you're only allowed to make network connections via HTTP and HTTPS, so attempting raw TCP sockets will definitely fail.
Take a look at this MSDN page on Plug-in Isolation, Trusts, and Statistics. It looks like there may be a way to relax the network restrictions by modifying a system registry entry to include tcp, etc, in the regex value. Below is an excerpt from the page. Note: I have not done this myself, so can't say for sure it'll work.
Sandboxed plug-ins and custom workflow activities can access the
network through the HTTP and HTTPS protocols. This capability provides
support for accessing popular web resources like social sites, news
feeds, web services, and more. The following web access restrictions
apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving those credentials.
These default web access restrictions are defined in a registry key on
the server that is running the Microsoft.Crm.Sandbox.HostService.exe
process. The value of the registry key can be changed by the System
Administrator according to business and security needs. The registry
key path on the server is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\SandboxWorkerOutboundUriPattern
The key value is a regular expression string that defines the web access restrictions.
The default key value is:
"^http[s]?://(?!((localhost[:/])|([.])|([0-9]+[:/])|(0x[0-9a-f]+[:/])|(((([0-9]+)|(0x[0-9A-F]+)).){3}(([0-9]+)|(0x[0-9A-F]+))[:/]))).+";*
By changing this registry key value, you can change the web access for sandboxed plug-ins.
I am specifying maxItemsInObjectGraph in the server config file but while creating client config file, this attribute is ignored and i have to manually add it in the endpointBehaviors section.
Is there a way i can make some changes in the config file so that everytime i generate client config and proxy via Svcutil.exe, this behaviour is automatically included in the client config file?
i tried ading [ServiceBehavior(MaxItemsInObjectGraph = 2147483647)] to the service interface but it gives me an error saying Attribute 'ServiceBehavior' is not valid on this declaration type. It is only valid on 'class' declarations.
Behaviors are typically local settings (you can have different values for client and server, and the communication can still work out fine), so they're not exposed in WSDL (and so svcutil will not be able to find that value).
You have basically 2 choices: update the client config every time you generate, or in code, when you create an instance of the proxy class, update the MIIOG property, similar to the code below.
ServiceClient client = new ServiceClient();
foreach (var operationDescription in client.Endpoint.Contract.Operations)
{
DataContractSerializerOperationBehavior dcsob =
operationDescription.Behaviors.Find<DataContractSerializerOperationBehavior>();
if (dcsob != null)
{
dcsob.MaxItemsInObjectGraph = int.MaxValue;
}
}
Note that if you are handwriting the client implementation instead of using auto-generated stubs, the Endpoint is available through the ChannelFactory used to create the channel for the service interface.
No, that is another behavior which is configured per participant. Each client has control over this property and service doesn't expose this property because it could be considered as security issue.
If your problem is mainly about development (where you don't want to modify your behavior every time you refresh the reference) you can use commonBehaviors section which can be defined only in machine.config:
<commonBehaviors>
<behaviors>
<endpointBehaviors>
<dataContractSerializer maxItemsInObjectGraph="..." />
</endpointBehaviors>
</behaviors>
</commonBehaviors>
Common behaviors are added to every service / endpoint running on the machine. It is perhaps good for development but you mustn't forget that once you will prepare package for production you will have to add this configuration to production's config file - because of that it is better to maintain such configuration file continuously and use it on some build / test server.
Where can I set default config options for wcftestclient?
There are no default options. Default configuration is generated in the same way svcutil generates configuration when adding service reference. Information trasported in WSDL are used and rest of values is set to default values based on binding / behavior.
If you want to modify and reuse client config for WcfTestClient you can:
Open WcfTestClient and let it generate config for you
In Tools > Options unthick Always config when launching services. It will allow you reusing single config for subsequent WcfTestClient executions in the same project but in the same way it will not automatically modify config based on changes made in service configuration.
Edit client config with SvcConfigEditor and save it. It will saved modified config to your Documents\Test Client Projects directory. The config will be reused if your service will be executed from the same address.
I have a WPF application using service references to a WCF service. When doing updates on the service I need to update the service reference, so I right click it and hit "Update Service Reference".
Doing this results in duplicate entries in the App.config file of the client project.
It duplicates a binding under wsHttpBinding - adding an equal entry with postfix number in name: WSHttpBinding_ISomeService --> WSHttpBinding_ISomeService1.
And it duplicates the endpoint definition under binding such that there is one endpoint for each wsHttpBinding. This too is a pure duplicate except of the name.
Why does it duplicate the config? Isn't it just supposed to update the name? And how can I make it stop?
Which version of Visual Studio are you using? This is a known bug, which has been fixed in VS2010. Check out this link!
code-zoop says that this known bug is resolved in VS2010, but I'm getting it in VS2010 as well.
Happens when I manually modify the default value for the MaxReceivedMessageSize property (and others) of the basicHttpBinding in App.config (as per this post: WCF - How to Increase Message Size Quota)
Just thought I'd mention that this happens in VS2010 as well. For the moment, I'm taking Shiraz Bhaiji's advice and just deleting the duplicate, which seems to be working for the moment being.
This has also happend to us on a few occasions.
You need to remove the duplicate, otherwise it will crash at runtime. The client looks in the configuration file to find where it should send a request to Interface(WCF contract X), finds more than one, and crashes.
one workaround is to put the service agent (web reference) in its own DLL and reference it from the main project.
it won't touch your service agent config in your web.config when you do Update Referene and as a bonus you'll have a project with up to date serviceagent config if you ever need to compare the default configuration with what you actually have in web.config
also has the benefit that if you have one service agent referencing another it will share the types
MAIN DLL > ServiceAgent1 DLL > ServiceAgent2 DLL
If ServiceAgent1 and ServiceAgent2 have shared types you won't get two generated duplicate classes