|
>
 Thursday, July 27, 2006
 |
|
 |
|
|
|
|
|
There's a nice little diagnostic tool that ships with the SDK for .NET 3.0 - svctraceviewer.exe. You WILL need this tool. It is a great way to inspect messages when things are going as expected, you can see the service model trace to inspect components leading up to an exception, you can see the details leading up to a service fault, more than is shown in the inner exception at times.
Here's an example configuration for the service-side for June/July CTP:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
...
</services>
<diagnostics performanceCounters="All" wmiProviderEnabled="true">
<messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="100000"/>
</diagnostics> </system.serviceModel>
<system.diagnostics >
<sharedListeners>
<add name="sharedListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\logs\servicetrace.svclog" />
</sharedListeners>
<sources>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
<listeners>
<add name="sharedListener" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
<listeners>
<add name="sharedListener" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
To view trace output launch svctraceviewer.exe and open the .svclog file. The Messages tab will take you directly to the actual messages that move between client and service, including full XML output (excluding binary data). The items in yellow are warnings, items in red are exceptions...where you can view details of the exception in the XML dump. Make sure you scroll all...the...way...down and look for the details of the exception...good stuff in there (or, bad stuff...I guess, if there is an exception).
|
|
|
 |
|
 |
Monday, March 20, 2006
|
|
|
|
|
|
|
|
|
Updated 04/09/06
See the previous few entries with code for my interoperability tutorial, and web services tutorial. Collectively they include the code for this session. Thanks!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
UPDATED: 3/27/06
At last, here are the links to our interop code from the tutorial at SD West. For those that didn't attend, we covered the following:
- OASIS Web Services Security (WSS) between .NET 2.0/WSE 3.0 and BEA WebLogic Workshop 8.1 with SP5
- Reliable Messaging between WCF and BEA WebLogic 9.0
- Anant (BEA) and I pulled this one together, once again Kirill providing some great human interoperablity with feedback from some of the earlier interop plugfests
- MTOM between WCF and Axis2
Please enjoy!
|
|
|
|
|
|
|
Wednesday, March 08, 2006
Wednesday, February 01, 2006
|
|
|
|
|
|
|
|
|
I blog when I have time and have something important to share, but I don't always have time to blog everything important I have to share (that's what articles and books are for I guess)...sometimes I blog just to hook you up to content references for events I've been part of...but today...I'm just blogging to vent my frustration with code snippet management in Visual Studio 2005. Aaarrrrghhhh...
Don't get me wrong, code snippets rock for productivity, but creating your own and getting them to freaking appear in the right place seems like a feat of great energy and time that I really do not have...sigh...but I took the time anyways because I figure if I just spend 2 hours (or 7200 seconds) now to get it working, then spend and extra 5 minutes (or 300 seconds) creating snippets for my repeatable code...it will pay off after I use about 200 snippets. Assuming I use about 3 code snippets per code sample, and that I create several code samples per day for my WCF book, not to mention other code samples and vertical slices for clients...I should be able to recover this time about 20 days time or less. Of course, I'm not factoring in time to write this blog...
So here goes my experience creating code snippets:
Creating new XML config snippets, no problem at all. Just copied an existing code snippet sample and away we go! Off to a good start.
Adding the code snippet to the Code Snippet Manager. Well first of all, figuring out what Add... versus Import... mean in that dialog is a pain. No, I didn't take the time to read an article about it...and frankly I expected it to be pretty easy to figure out. Well it seemed like sometimes Add worked, sometimes it didn't, but I seem to have finally figured out that you are supposed to select a directory that holds the code snippet type for the language you are adding folders to.
So, I created a WCFSnippets folder with two subdirectories:
\WCFCode -> holds my C# WCF code snippets
\WCFConfig -> holds my XML WCF code snippets for configuration
Then, from the code snippet manager, you select XML for the language and click Add. What you are supposed to do is find the folder with your XML snippets, so I navigate to \WCFConfig...but don't just navigate to that directory, drill all the way into the directory where the snippets are stored before you select the directory. Here are the screenshots: wrong, right and result...respectively.
For C# or VB.NET snippets, just select the right language, and drill into the directory where those are located.
Extra crap in my code snippets intellisense...make no "sense". I know the above seems really super easy...and it is once you know where to navigate and how to organize your stuff. Still, I had all kinds of extra crap left over in my snippet manager, and in my code snippet intellisense...let me explain.
After trying Add/Import, I was left with extra folders in my code snippet manager, that somehow didn't reflect all the snippets I was creating...it was nuts...I was going nuts...maybe I am nuts...anyways it turns out that Import is not really necessary if you have added your snippets folder according to the Add method I explained. Any new snippets you create in those custom folders will now appear in the magical snippets list. But, if you want to copy (import) a snippet from somewhere and put it into one of your folders (or, one of the predefined snippet folders for VS) you can Import.
If I navigate to my WCF configuration snippets folder and select a snippet, I will be presented with the already existing XML folders (preexisting or resulting from Add). You decide where you want the snippet to go and a copy is made there. Watch out for dupes!
The bugger of it is, you can't remove snippets. You can add them, but they will never go away...that is unless you delete the actual snippet from the file folder. So much for snippet management. You can remove folders, just not those living in the VS snippet folder, that's too official to remove...
Things to watch out for.
1. Beware not to add your snippet directories more than once. Or not to add the parent directory, only to decide on the child directory as in my WCFSnippets and WCFConfiguration example earlier. What happens? Well, somewhere out in snippet configuration land (a lost land that I cannot find) there is memory of every (wrong) directory you ever added using Add...and you can't freaking get rid of it. Well...I'm sure you can, but I care not spend more time to figure out why...perhaps someone else can tell me!!!
2. Make sure you put the correct language in your snippet code. If you call it XML but it's really C# (spelled csharp in snippet terms) you won't see it appear in your C# snippets after all...another ghost I chased...for a short while.
Sample snippet...for your time...more to come :)
<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippet Format="1.0.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<Header>
<Title>system.serviceModel.diagnostics</Title>
<Author>Michele Leroux Bustamante</Author>
<Shortcut>serviceModel.diagnostics</Shortcut>
<Description>Sample system.serviceModel.diagnostics section.</Description>
<SnippetTypes>
<SnippetType>Expansion</SnippetType>
</SnippetTypes>
</Header>
<Snippet>
<Declarations>
<Literal>
<ID>perfCounters</ID>
<Default>true</Default>
<ToolTip>Enable performance counters: true|false</ToolTip>
</Literal>
<Literal>
<ID>wmiProvider</ID>
<Default>true</Default>
<ToolTip>Enable WMI provider: true|false</ToolTip>
</Literal>
<Literal>
<ID>logEntire</ID>
<Default>false</Default>
<ToolTip>Log entire message content (beware! production performance hit): true|false</ToolTip>
</Literal>
<Literal>
<ID>logMalformed</ID>
<Default>true</Default>
<ToolTip>Log malformed messages (or, provide your own logging mechanism, don't do both!): true|false</ToolTip>
</Literal>
<Literal>
<ID>logServiceLevel</ID>
<Default>false</Default>
<ToolTip>Log messages at service level: true|false</ToolTip>
</Literal>
<Literal>
<ID>logTransportLevel</ID>
<Default>true</Default>
<ToolTip>Log messages at transport level: true|false</ToolTip>
</Literal>
<Literal>
<ID>maxLog</ID>
<Default>100000</Default>
<ToolTip>Maximum message log count (runs out fast, must backup the file!)</ToolTip>
</Literal>
</Declarations>
<Code Language="XML" Format="CData">
<![CDATA[ <diagnostics performanceCountersEnabled="$perfCounters$" wmiProviderEnabled="$wmiProvider$" >
<messageLogging logEntireMessage="$logEntire$" logMalformedMessages="$logMalformed$" logMessagesAtServiceLevel="$logServiceLevel$" logMessagesAtTransportLevel="$logTransportLevel$" maxMessagesToLog="$maxLog$" />
</diagnostics>]]>
</Code>
</Snippet>
</CodeSnippet>
|
|
|
|
|
|
|
Tuesday, January 31, 2006
|
|
|
|
|
|
|
|
|
Ok folks...here's a sample (er full blown wicked application) that makes all my 6 project WCF samples that include security, transactions, reliable messaging, MTOM file uploads and more...look like Hello World...
Clemens Vasters, founder of Newtelligence, leader of the community project dasBlog (my blog engine), well known blogger/speaker/writer/thought leader, and a person I am proud to call my friend...has really done it this time.
Newtellivision, get it here (he's popular, hence the site might be slightly slow)...
http://www.newtellivision.tv/2006/01/30/GoingOutAndInWithABangNewtellivision.aspx
|
|
|
|
|
|
|
Wednesday, January 25, 2006
Tuesday, January 24, 2006
Thursday, January 05, 2006
|
|
|
|
|
|
|
|
|
I had some questions on versioning contracts, so I thought I'd write up a quick list of tips on this subject, some of which applies to any platform where contracts drive communications (read: web services in general).
Point #1 – breaking changes require contract versioning
Here are an example of some breaking changes that cause serialization requirements for a service to change:
- Remove operations
- Change operation name
- Remove operation parameters
- Add operation parameters
- Change an operation parameter name or data type
- Change an operation's return value type
- Change the serialized XML format for a parameter type (data contract) or operation (message contract) by explicitly using .NET attributes or custom serialization code
- Modify service operation encoding formats (RPC Encoding vs. Document Literal)
Point #2 – modifications to implementation semantics require contract versioning
Even if there are no contract versioning violations from #1, if the implementation semantics of an operation have changed this warrants contract versioning. If your clients call an Add operation and you decide that Add will no longer add, it will subtract...then your existing clients should continue to call the "old service operation" and you should create a new operation for the subtract operation. If the change is subtle, and if clients will not be affected by the change, no need to create a new operation.
Do you have to version the contract if you add a new operation? Not necessarily, however if you have a contract that has been published with methods A, B and C...and clients have been programming against that contract, then when you add methods D and E it would be good to provide a distinction between the original contract, and the new one. If the new methods are still related to the same contract, you can provide a new contract by the same name, with a new namespace.
Point #3 – you can avoid contract versioning
You can reduce the changes of #1 and #2 being directly violated. For example, a parameter can receive alternate serialization formats, the service can opt to forgive missing elements, or ignore extra elements. You can design the service contract to be forgiving by things like this:
- Using optional elements in data contracts
- Using IXmlSerializable types and “handling” serialization differences behind the scenes
- Intercepting parameter serialization and deserialization at a lower level to overcome differences
You can also avoid parameter list modification issues by avoiding specifying a list of parameters in your methods. For example instead of:
use:
void Add(AddRequest message);
where AddRequest is a type that receives x and y:
[DataContract] public class AddRequest
{
[DataMember] public int x;
[DataMember] public int y;
}
Now, if you add another public member to the AddRequest type, and make sure it is not a required element, old clients can send their reduced set along:
[DataMember(IsRequired="false")] public int z;
You can preserve unknown serialization elements as well, on the client or on the service side, by implementing IUnknownSerializationData in your data contract types. You can find out more about this in my book chapter on Contracts, which will be posted when I launch my book blog this week.
|
|
|
|
|
|
|
Saturday, December 31, 2005
Wednesday, November 30, 2005
|
|
|
|
|
|
|
|
|
I posted some WCF samples earlier in this blog, and they were built against a (then) unreleased version of the bits. Now you can get them too, here: http://www.microsoft.com/downloads/details.aspx?FamilyId=E5376297-DA10-4FC3-967D-38C96F767FC4&displaylang=en
This build works with VS 2005, the steps to build a machine:
Enjoy! Check out my earlier Indigo posts for code samples. Some are built for PDC bits, later are built for these bits... thought I can't absolutely guarantee it since I am using early builds before they are public. Let me know if you find incompatibilities so I can try to help.
|
|
|
|
|
|
|
Wednesday, November 16, 2005
|
|
|
|
|
|
|
|
|
I delivered these two WCF/Indigo talks at DevConnections last week, and this post contains sample code demonstrated in both talks.
NOTE: I am building all sample code with November 2005 bits, so they will NOT work with PDC bits. I will update these samples for the very next public CTP so you can look for that.
- HelloIndigo – a simple WCF service, decoupled host
- ComplexTypes – serialization via DataContract
- ComplexTypesV2 – serialization of base types and interfaces
- CustomMessage – my WS-Transfer implementation is not compiling with the current build I have, so I will update this when the issue is resolved
- Messaging – illustrates sessions and instancing
- SimpleQueue – simple msmq example
- WindowsAuthentication – windows auth and security context information display
- SecureService – windows auth and username auth demo, with custom membership provider
I am also posting the slides from this talk. I took this talk over at the last minute for Clemens, and we didn’t have time to get the slides in for the printed books.
VID307DesigningServicesWithIndigo.zip (55.37 KB)
I also promised a tutorial, and my plan is to get permission from my publisher to post a few labs from each chapter in my book, including the security tutorial I showed in the security session. I will update this post to let you know where that will be found…stay tuned for a few more days.
|
|
|
|
|
|
|
Monday, October 03, 2005
|
|
|
|
|
|
|
|
|
Never ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever write service contracts and implementations inline.
With the PDC bits for WCF, using the Indigo Service template is like opening a box of chocolates...you never know what you'll get...IService, IMyService, IIndigoService...but that's just Beta stuff...
For Web sites the template generates the .svc endpoint and service implementation, for other project types it generates only the service implementation. Normally the service implementation would be in a .cs or .vb file (pick your language)...and this is true in all cases but one: adding a new Indigo Service to an existing Web site project in Visual Studio.
This template is evil...it creates inline code like this, with all the implementation in the target IIS endpoint file:
<%@ Service Language="C#" Class="IndigoService" %>
using System;
using System.ServiceModel;
[ServiceContract()]
public interface IIndigoService
{
[OperationContract]
string MyOperation1(string myValue);
}
public class IndigoService : IIndigoService
{
public string MyOperation1(string myValue)
{
return "Hello: " + myValue;
}
}
Now if I want to host this service outside of this Web site application I'll have to copy the service code into another file somewhere, or migrate this code to use a class library and share it. Why would I not just create the service in the class file from the beginning?
This may change before release...but just in case bookmark this post ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Getting back to my earlier brain dump on the many ways you can create WCF services today...I have uploaded two samples:
The first sample is a solution with three projects: service, host and client. The service is a class library with a HelloIndigo.Service implementation, the host is a console application that initializes the ServiceHost for the service (self-host over HTTP), and the client consumes the service. ServiceFromScratchConfig.zip (54.5 KB)
THe second sample is a solution with two projects: a Web site created from the Indigo Service template, and a client to consume the service. The Web site acts as the host for the service (through IIS) but actually references the HelloIndigo.Service from the previous example. IISHostedService.zip (22.11 KB)
Same service, two hosts with possibly different bindings, behaviors, instancing.
If you always designer your services to be “moveable“ you will have an agile service-oriented system on your hands. The service contract and implementation (as expected) does not change, that should be appropriately versioned once it has been published. Oh, and guess what? Since the service is contained in a separate class library (assembly) it can be versioned appropriately with CLR versioning as well as contract versioning semantics.
So I have now explained why you should never use the Indigo Template “as is” when you build Web site, console, class library, or other applications that contain or host services. Sorry...templates are for kids...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I had several conversations this weekend with Steve Swartz (one of my favorite people, not just because he's smart, but he's a really cool guy too!) about best practices in various aspects of the service model. I'll eventually get a chance to blurt all of my thoughts on this (and confirmations a-la Steve) but let's start with the subject: base address and endpoints...how “should” it work?
Consider this example that creates a new self-hosted service with a base address and endpoint Uri as shown here hard-coded:
Uri baseAddress = new Uri("http://localhost:8000/HelloIndigo");
using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.Service), baseAddress))
{
host.AddEndpoint(typeof(HelloIndigo.IService), new BasicHttpBinding(), new Uri("http://localhost:8000/HelloIndigo/Service"));
host.Open();
Console.ReadLine();
host.Close();
}
Seems harmless, and it will work. Clients will bind against the target Uri of the endpoint:
http://localhost:8000/HelloIndigo/Service
But the truth of the matter is that the base address should be relied on as the...well as the base address for all endpoints that share the same protocol, port, etc. In the above example that would suggest that when I add an endpoint to the service host, I should only submit “Service“ as a string (something you can do with one of the overloaded methods for AddEndpoint):
host.AddEndpoint(typeof(HelloIndigo.IService), new BasicHttpBinding(), "Service");
The same goes for declarative configuration for the service host, no need to specify the complete Uri, it will be inferred from the base address:
<service type="HelloIndigo.Service" >
<endpoint address="Service" contract="HelloIndigo.IService, HelloIndigo" binding="basicHttpBinding" />
</service>
This makes your services more configurable, modify the base address and relative Uri will follow suit.
|
|
|
|
|
|
|
Sunday, October 02, 2005
|
|
|
|
|
|
|
|
|
I thought I'd share this observation in the interest of coding practices for the WCF. For client applications invoking services, you'll see lots of samples already out there that use the following syntax:
ChannelFactory<IService> factory = new ChannelFactory<IService>("");
IService proxy = factory.CreateChannel();
string s = proxy.HelloIndigo();
But, the proxy generated for you, that inherits ClientBase<T>, will handle creating the channel for you so you can use syntax like this:
using (ServiceProxy proxy = new ServiceProxy(""))
{
string s = proxy.HelloIndigo();
}
Besides its relative simplicity, another slant in favor of using the proxy generated for your service is that its base class implements IDisposable, therefore you can use the using statement to expedite cleanup of channel resources.
There are probably cases where you will need to interact with the channel directly, though none come to mind at the moment...for the most part you should be able to configure the channel using binding configurations.
|
|
|
|
|
|
|
Wednesday, September 28, 2005
|
|
|
|
|
|
|
|
|
If you weren't at the PDC, you can still get the latest WinFX bits, with the latest drop of WCF and WPF:
http://www.microsoft.com/downloads/details.aspx?familyid=ffd636f0-86e9-41e8-9e1c-100a4cc4888f&displaylang=en
Of course you need MSDN subscription to install the latest Visual Studio 2005 bits on top...but the RC1 candidate is available up there, so I recommend you use that...apparently it only runs with Beta 2, so you can't work with the latest and greatest 2005 bits today and get WinFX running.
Do this if you want to be able to run any code samples I post on Indigo...er...WCF WCF WCF WCF...
ADDING MORE INSTRUCTIONS
I found a great blog post explaining all the steps for PDC DVDs or downloaded bits here: http://www.longhornblogs.com/rrelyea/archive/2005/09/16/PDC2005Software.aspx
These are the download instructions from Rob Relyea's blog:
1. Operating System Required - Windows XP SP2 or Windows Vista 5219 (not Windows Vista beta1!)
2. WinFx CTP installation
This installs WinFX on the machine...end users will need this done.
WPF (fka "Avalon"), WCF (fka "Indigo"), and .NET Framework 2.0 all get installed with an integrated setup.
3. Visual Studio (Beta 2!!!) (or you can also install Visual Basic Express or VC# Express - just make sure it is "Beta 2"!) Sorry, there is currently no build of WinFX that is compatible with RC or RTM builds of VS!
Once the install is done, make sure you do step 2 of the VS setup...install Help content - use it offline if you want it to work its best with WinFX SDK content to come later.
4. Windows WinFX SDK
This installs a ton of help content (samples, documentation) and some great tools (xamlpad, etc...)
5. VS Extensions for WinFx
This installs Project Templates and Item Templates for Visual Studio.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sometimes it is really helpful to have different ways to build things...like WCF services for example...I can approach it from many different starting points. If I know I am going to host my services as part of a Web site/application...I might start from a different path than if I was building a truly service-oriented application that may or may not be always exposing services over HTTP and/or through IIS.
So you can do any of the following to create a service:
a) Create a new Web site project using the Indigo Service template and selecting HTTP (creates an IIS virtual directory for you, that's great!)
b) Create a new Web site project using the Indigo Service template and selecting File System (this creates a file-based Web site, no IIS virtual directory, hosted with Cassini Web server)
c) Create a new Class Library project then add an Indigo Service template item to it (no virtual directory is created for you, and no .svc endpoint is created...because the idea here would be to host this service “wherever you like“)
d) Create a new Console Application project then add an Indigo Service template item to it (no virtual directory or .svc but you can add self-hosting code to this application, coupling the host and service in one)
Some observations:
Option a) is useful for testing IIS services because it quickly generates a project that and creates the appropriate IIS virtual directory.
Option b) is problematic for a few reasons. First because in general, Cassini testing does not yield the same results as IIS-hosted testing when we’re talking about anonymous vs. authenticated access. Second because it requires NTLM authentication by default, requiring extra steps to enable access to your services on the development machine (I'll make a separate post on this)…possibly settings that will leak into deployment configs for QA and production if not caught. Whenever possible I think we should develop in the environment we will deploy in.
Both a) and b) have another drawback, that the service interface now gets lumped into the deployment of the ASP.NET Web site (the project it belongs to). That means either deploying source (hopefully no one will really deploy source in ASP.NET 2.0...just because you can) or precompiling the site (so now the code for the service is lumped into the ASP.NET application DLLs and it must now be versioned with those DLLS). This tightly couples the service (which should be an agile component of a system) to the ASP.NET application it is exposed through. I recommend there NOT be a template for creating indigo services with Web sites for this reason…because it moves you away from a pure service-oriented design.
Option c) is best because it implies that the service interface is part of a component that can be distributed and used by either an ASP.NET site, or a self-hosting environment, but coupled to neither.
Option d) couples the service to the host, nice for demos, not practical in deployment.
Of course, we always want tools for testing, that will make us quickly productive, and for that reason I say perhaps we are missing a few things. If we can have templates for services exposed as part of Web sites ( a) and b) ), we should also have template for creating self-hosted console services ( d) ), or IIS hosted class libraries ( c) with a twist ). The last item there is what we are missing perhaps, just in productivity terms:
e) Create a new Class Library then add the template item for IIS Hosted Indigo Service. This would create the IIS vdir and give us the darned .svc file for our class library, maybe even set the Build directory to \bin instead of \bin\debug or \bin\release so it will work without editing that.
Of course e) goes against my initial argument -> to force developers to build services in a service-oriented and decoupled manner...which would mean get rid of all but c) and watch people scream. I think what we'll need instead is a) through d) (plus e) if I get my wish) and we'll need to educate people why real services should be designed with c) because you know that a million and one code samples are already flying out to the Web that don't do c).
I'll post some samples separately, I wanted to get my rant out first. That feels better.
|
|
|
|
|
|
|
Thursday, June 30, 2005
|
|
|
|
|
|
|
|
|
If you're wondering if there are redistributables for the Indigo/Avalon Beta 1 RC, there are! You can find them here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=b789bc8d-4f25-4823-b6aa-c5edf432d0c1&displaylang=en
I'm installing this on a test client machine that I don't want littered with the entire Visual Studio installation for verifying some of my Indigo builds. We shall see...later...if I can as easily uninstall this build when (if) I need to revert to the 2005 bits on the same rocking 2GB RAM machine that I am so happy I have now for running all my VPCs.
But don't confuse this download with a full installation that includes samples and SDK. If you want to play with these bits in the Visual Studio environment, do the following:
- Install the Indigo/Avalon Beta 1 RC Win SDK (this link is on the same download page, but can be tricky to find if you don't read carefully).
- Install Visual Studio 2005 (since you have installed a later version of the runtime to the machine, Visual Studio will point to those bits).
I have been able to do this with the Visual Studio Team Client edition and the Visual Studio Standard edition, without any problems thus far.
|
|
|
|
|
|
|
Tuesday, June 21, 2005
|
|
|
|
|
|
|
|
|
It's just not enough to play with a technology...you really have to burn a few wasteful hours on something ridiculous before you can really feel the love. I love Indigo, I hate that I just spent 3 hours on what I'm about to describe to you. I hope that these 3 hours are well spent if it saves one of my 4 readers the trouble on the road to Indigo...
I have this relatively complex service I am working on that implements contracts for the WS-Trust and WS-Transfer specification (more on those another time...but you get the idea, lots going on). And since I'm implementing a standard contract, I don't need to create a proxy for the client, instead the client can dynamically create a channel to access the service, binding to the same IWSTransfer or IWSTrust contract definition (interface-based). I was a little bit curious how this would play out, what little steps I might miss getting the client side channel properly configured, exposing the service endpoint correctly since it has multiple contracts...so I expected trouble when I first ran the client code to hit the service.
First, my client started getting Access Denied errors hitting the service. This was easy enough, I had to tweak a few things on my service directory permissions.
Second, and less obvious, I start getting the hideous “Internal Server Error 500“. So begins my trials to find the cause, without really knowing “what I don't know yet” about Indigo.
The saga begins...
1. I run the service in the browser, and I get this strange error that indicates it can't find the service DLL.
<%@Service language=c# Debug="true" class="IDesign.Samples.Indigo.WSTransferService" %>
<%@Assembly Name="Service" %>
I check, Service.dll exists, everything built fine, so I test another service that I know works, and no problems showing it the browser.
2. Could it be that my complex interfaces are causing a problem? I am after all exposing two contracts, perhaps I missed something?
So I simplify, and copy a test service that I know works, into my WSTransferService' project, and I modify the configs to expose only that service just to check it out. I use the same test client to hit this test service, simply reconfigure the endpoint from http://localhost/vdiroriginal/service.svc to http://localhost/vdirnew/service.svc. IT DOESN“T WORK! So, now, what am I to think? Same error, different project, different virtual directory. Hmmm...
3. Could it be the Virtual Directory settings?
I check IIS, compare them, I find my service doesn't have “Scripts and Execution“ enabled, so I'm thinking EURIKA, I'VE FOUND IT! No go, same error, damn!
So I use the same Virtual Directory and instead redirect it to another physical directory, and use the same simple test client, and I simply swamp the test client configuration from the service it normally hits, to the same service in a different directory. That means the test client configuration is the same, the test service configuration is the same, but the location is in a new physical directory. Still, no go.
4. Could it be some project settings?
I check the project settings, they are identical, so there is no special post build step that could lead to the error.
I know what you're thinking, “What was the freaking solution then??? Why tell me all of this crap???”. Answer: Well, just to give you an idea of the other possible things you might need to check for other service issues...even if they don't apply to this one. I'm almost there...check it out...
5. Project settings, project settings, project settings...and then it hit me...
The service DLL, you know the one it said in #1 above “can't be found“. Yeah, well the error message couldn't be more clear now could it? The problem is, when you create an Indigo service, you usually create a class library and add the .svc and related code there. If you deploy the service, you deploy as follows:
\root
service.svc
web.config
\root\bin
service.dll
Yeah, well class libraries default to build the DLL in the \debug or \release folder right? Now you feel my 3 hours of pain. I doubted myself, and I shouldn't have. I was sure it was a problem with one of: directory access, virtual directory settings, service configuration errors...or some magical thing I just don't get about hosting in IIS.
NOT
I had to change my project settings to build the output files in \bin instead of \bin\debug or \bin\release.
Had I deployed the app, of course I would have used the correct structure...but I was testing from within the IDE...and that my friends is my first official ghost chase with Indigo. Stupid? Yes. Could it happen to you? Not anymore.
|
|
|
|
|
|
|
Monday, June 13, 2005
Thursday, June 17, 2004
|
|
|
|
|
|
|
|
|
In many presentations of late I have mentioned to folks the preference of Enterprise Services over .NET Remoting. In part to reduce the risk associated with rolling your own security model across boundaries (among other things), and due to the fact that the Indigo team at Microsoft recommends Enterprise Services as the way to build your component architecture today, to better migrate to Indigo tomorrow.
Here are some references I found on the subject on Rich Turner's blog (he's a PM) and a video on the MSFT site. If I find more, I'll add to comments. If you have your own proof, or have questions/concerns on this subject, YOU add to comments :)
Cheers.
|
|
|
|
|
|
|
|
|
ON THIS PAGE
|
|
|
|
SEARCH
|
|
|
|
CATEGORIES
|
|
|
|
ARCHIVES
|
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat | | 28 | 29 | 30 | 1 | 2 | 3 | 4 | | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 12 | 13 | 14 | 15 | 16 | 17 | 18 | | 19 | 20 | 21 | 22 | 23 | 24 | 25 | | 26 | 27 | 28 | 29 | 30 | 31 | 1 | | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|
|
BLOGROLL
|
|
|
|
|
 |
|