We Keep Coding

Running a .asmx Web service as a Windows Service

I'm a total novice on asking questions on this forum - I hope I ask this question correctly.
The problem I'm trying to tackle is this: I have a Visual Studio 2010 project which is for a Web Service. The class which does the work is defined in a ".asmx" file. The class inherits from the "System.Web.Services.WebService" class.
It runs happily on IIS on a server. Clients can make SOAP calls to the Web Service and it actions the requests and sends a response. That's all fine.
The problem is that I want it to run on a Windows 7 PC on which I can't install IIS. So I wish it to run as a Windows Service (if possible). The only "client" of the service will be the user on that PC.
In other words, I wish to run all the code that is in my .asmx as a Windows Service (if possible).
In an ideal world I'd be able to re-use my existing .asmx (if possible), and not have to copy and paste all my code across to a new Windows Service solution.
So my goal is to find the up-to-date way of running an .asmx Web Service as a Windows Service. I'm hoping someone could point me in the right direction on how I accomplish this.
I've done quite a bit of searching, and it looks as though this is very much possible to do. The problem is that a lot of solutions out there, appear to be slightly out of date. Or I've got my concepts rather mixed up.
Based on "How can I deploy my WCF Service without IIS?", I've had a look at a few things.
The closest I've come is this: "https://msdn.microsoft.com/en-us/library/ms751414.aspx". However, in this example, the actual class which does the work (the calculator) is actually contained in the service itself. I would have thought you could have separated them out. In other words, have the service create instances of a class that comes from my .asmx file.
The second closes I've come across is "https://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic4", however this is .NET 3.0 and VS 2005. I'm also struggling to understand how to link my existing class into the service.
The other solutions I encounter suggest adding references to "Microsoft.Web.Services3.dll", "System.Web.dll", and "System.Web.Services.dll", although a few people seem to think this is called WSE which was updated to WCF in .net 4.0 and so I should not be using it.
Any pointers as to where I get started?

In an ideal world, you would switch to WCF, as it can easily self-host, host in a service, etc. And there are plenty of examples out there. It is easy enough to migrate the code from ASMX to WCF. But this is 3.5, as NetFX (WCF, WF and WPF were released under 3.5).
With ASMX, you need a server to host with. You can create a simple "server" with the HttpListener class. This may be heavy enough for your purpose.
https://msdn.microsoft.com/en-us/library/system.net.httplistener(v=vs.85).aspx
IIS now has a hostable core, which can be used with newer versions of .NET, but if you cannot install the newer versions and have to leave the client machines at 3.0, it is probably not your best option.
You may be able to dig up old source for Cassini, which was Microsoft's implementation that eventually became the hostable web core.
Back in 2008, someone snagged the server in VS, which might be an option. Note that the version on this page is for VS 2008, which means 4.0:
http://www.codeproject.com/Articles/23939/Light-IIS-Run-Asp-net-without-IIS
Ultidev has a server that is reported to self-host: http://ultidev.com/download/default.aspx
Hope one of these helps.

Just for completeness, here's how I solved this:
In the end I went with running IIS on client PCs and just continued using the asmx.
I found that converting the asmx to WCF to be quite tricky. To be precise, it was the thread handling within the asmx (thread handling coded by someone else), that I found to be quite hard to convert. To explain further the asmx which I was trying to convert, did all its work in a class which inherited from "System.Web.Services.WebService". It could therefore, create an "Application" instance, which it then used to do its thread management.
So rather than try and do the same thing, using "System.ServiceModel" (which doesn't allow me to create an "Application" instance), I thought it easier to just to use IIS on the client PCs. I figured this was a better use of time than recoding a fairly complex asmx. A bit defeatist I know.
Kind regards to all.

Calling C# .NET Service From C++ Application?

I have an old MFC app written in Visual Studio 6. This will at some point be rewritten in C# .NET. However, before then I have to write a couple of new Windows services for the existing application. The others were written in ATL. What I would prefer to do is write these new services in C# .NET so that when the rest of the application is rewritten, these don't need to be.
Is it going to be possible to call the interfaces on the libraries hosted in a .NET windows service from the old application? If so, could you please explain how.

Absolutely. You're looking for a feature of .NET called COM-Interop.
http://msdn.microsoft.com/en-us/library/kew41ycz%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/magazine/cc163494.aspx
The second link has an ATL example.
EDIT:
Based on your feedback in the comments, let me expand on this...
Ah - you're right about the sample on that page.
The first link is really where you want to start for all the details. If you follow the links, you'll find this page:
"Exposing .NET Framework Components to COM"
http://msdn.microsoft.com/en-us/library/zsfww439%28v=vs.71%29.aspx
Essentially, it's just a matter of applying a series of attributes to your classes and properties, and then generating the appropriate registry entries on the client machine (which .NET has a tool to do - see: http://msdn.microsoft.com/en-us/library/bctyca52%28v=vs.71%29.aspx)
I've done this several times myself for .NET projects people needed to call from VC++ and/or VB6.
Some other links that might be of interest:
http://www.codeproject.com/KB/COM/nettocom.aspx <-- Perfect example of what you're trying to do.
http://www.codeproject.com/KB/COM/Universal_CCW.aspx

I've done this exact thing with an MFC-based C++ application in Visual Studio 2008 and a .NET-based C# Windows service.
First, if you have not created the C# Windows services yet, I've got a couple of tutorials for creating the basic framework. The first tutorial provides a step-by-step procedure for creating the service and writing events to an application-specific event log. The second tutorial shows how to modify the service to install and uninstall itself from the command line, which I find of great use.
Second, you need to decide how you are going to communicate between your MFC application and your Windows service. Any kind of inter-process communication (IPC) model will work - sockets, pipes, shared memory, WCF, etc. Since you are wanting to migrate to .NET anyway, I would recommend using Windows Communication Foundation (WCF), which is the way I've done it. Specifically, I chose the named pipe aspect of WCF for my communication method based on the chart shown here.
If you go down the WCF route, you'll benefit from the fact that the communication between application and service is .NET-based. Thus, when you move your application to .NET, the communication mechanism won't have to be rewritten. The trick in the meantime is getting your MFC application to use the WCF code. To do this, write the WCF client code in a .NET assembly using C#. Then, use a C++ dll to bridge the gap between your MFC code and the .NET assembly. I've got another tutorial with step-by-step instructions for how to do this.
Hope this helps.

Silverlight - Send/Receive Data at runtime with JAVA

Yesterday I asked about what technology should I use to create dynamic web content here:
PHP, AJAX and Java
The suggested methods were JSP, JQuery, etc. But I thought maybe because I'm a .Net developer and I don't have any experience in web development but I have experience in WPF and C#, maybe I should go with Silverlight but the main problem here would be how can I communicate with the core part of my system which is implemented in Java?
So the main question would be: What is the best [and easiest to learn] method to send a piece of data to the Java part, get the result and use it in silverlight? A tutorial or simple example would be nice.
Thanks a lot in advance.

You should use Java Web Services as stated. Use WCF to invoke the Java WS by adding a Service Reference in Visual Studio by its url, then use the proxy classes generated automatically (located in Reference.cs) to invoke the WS. This is easy but remember SilverLight WS invocations are always asynchronous, so you must cath the OnCompleted event to get the results of the invocation. WS are slow but if the machines are in the same LAN, invocation could take a few milliseconds.
I think pipes are not your solution as SilverLight executes in a Sandbox and have many restrictions on what you can do.

This will depend on many factors, however a relatively easy approach would be to use Java Web Services. On the .NET side, WSDL will be picked up and transformed into proxy class by WSDL.exe from the Windows SDK. If, however, these two systems are on the same server (and intend on staying this way), you may decide to use pipes.

Database connection with Flex and C#/Asp.Net

I've started with Flex recently, I've noticed that some plugin for Visual Studio exist, instead of buying a licence for another program (Flex Builder).
I was wondering how I could manage to remotely connect to my database with a Flash/Flex application with the help of C#/Asp.Net.
If I've correctly understood what I've read in the last few days, there is basically no way to 'query' to a database with Flex 3. So I suppose there is another way by using a webservice in C# on the database server that would respond to the Http query from Flex.
Am I right or totally of the track? If you have any other thoughts about this, please share.

I prefer (and recommend) using Webservices for the communication between Flex and C#. It's easy to use, and they both support serialization, so you can easily transfer Strong-Typed Objects. More on Flex and .NET can be found at http://www.adobe.com/devnet/flex/flex_net.html
Alternatively, you could consider using WebORB. This program functions as a gateway between and Flex, and enables you to use the Flash RemoteObject API for the communication to C#. More on this can be found at http://www.adobe.com/devnet/flex/articles/flextodotnet_remoteobject.html.

You really should consider using FluorineFx.
It takes about 5 minutes to set up an will allow Flex to call your methods like a service. You can then pass classes back and forth from .NET to Flex and back.
It's also the standard form of communication by Adobe, it's free and it's super fast.

Your understanding is correct. Flex is intended for developing client-side applications, and communication with a database is done through a server-side application.
Pretty much the same as building a JavaScript application. Though, Flex has several additional options for communicating with the backend. Webservices are great in a lot of cases, but the other options are worth looking into.
Here's a pretty happening article on the topic, if you haven't already seen it.
http://www.dehats.com/drupal/?q=node/33

Silverlight, Wpf Web App (xbap) or Click Once? Pros and Cons

We are starting a new project and I'm trying to decide which of the Wpf-esque develop/deploy strategies we should go with. In our case we are looking at quite a complex business app that will be used by 100s (not 1000s) of people, So I'm leaning towards a click-once app. My boss likes the idea of a Silverlight app as it means easier deployment. So which way should we jump?
The answer is, of course, "it depends".
So what are the pros and cons of each?
I'll start the ball rolling (Edit Added in some answers from artur carvalho):
Silverlight
Pros
Cross browser
Doesn't require full framework.
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
Cons
Can't interact with client's file system etc
Has less functionality compared with full Wpf (anyone got a good resource that documents differences?)
Single window
Single version
Wpf Web App (xbap)
Pros
Full Wpf.
Cons
Single browser
Requires full framework
Can't interact with client's file system etc
Single window
Single version
Wpf Click once
Pros
Full Wpf
Can work offline
Multiple windows
Multiple versions (con?)
Better access to low level parts of the computer
No downtime for maintenance
Cons
Single browser
Requires full framework
Slightly(?) harder to install.

First, I would evaluate whether a web client (ideally MVC+jQuery) can't do the job...
Assuming a full client is warranted:
If it is a business app that demands a client, I would tend to go with the full framework and ClickOnce; the main difference here (re deployment) is that the client must have the framework installed - but past that, ClickOnce deployment is very pain free. Actually, building a ClickOnce manifest is much easier than Silverlight etc, since the IDE will do almost all of it for you; you just have to host the files somewhere (could be a web URL; could be a network UNC).
This gives you much more control (and power) at the client, as well as a far greater range of existing resources to use (for example, if you need, you can use some legacy winform code on the WPF surface). The "requires full framework" is also one of the largest benefits: "has full framework".
You should also perhaps consider the 3.5 "client profile" setup; not sure how wide-spread this is in reality... but worth knowing about.

You didn't say if this is a company only application or a public facing one. That alone will decide it for you.
If company only, I would go with full WPF click once. This will give you everything.
Full framework should not be an issue. It's a one time install running in the background so it's not something that your decision should depend on. Cons: it runs in Windows only but if your company is Windows only, this should not be an issue.
However WPF apps could be resource hungry so you need to know if all your client machines are capable of running WPF apps smoothly.
If it's an Internet app, go for Silverlight: it runs under different operating systems.

PROs vs. ASP.NET Web Forms
No ViewState or "surprise crap"
o This applies to Silverlight as well. Silverlight brings the "desktop" experience to the end user and there is no ViewState that is used in Silverlight.
Faster server-side & client-side
o Silverlight is faster on the client/server side depending on how you look at it. Silverlight is compiled in a .NET subsystem of Silverlight. You have access to multithreading, LINQ, complex data structures, etc. The performance vs. an ASP.NET or AJAX/JavaScript application is it magnitudes times better because of the client execution and some of the items that normally are handled in a server BLL can be brought down to the client
Simplified model for multiple related views
o Silverlight supports the complete seperation of the data and the UI. Taking this further by just creating seperate views for say another consumer of Silverlight is pretty powerful. You can apply the same MVC/MVP pattern inside Silverlight and attain this level of abstraction. Jason mentions an example of being able to create a seperate view for an iPhone and only the View component has to change. This applies to Silverlight as well for different things. For example, I have large sized Silverlight app I want to port to SharePoint. I can create a "Smaller View" for SharePoint so it fits nicer into the UI. Furthermore, Silverlight Mobile is being private tested now. I would assume that same very powerful level of abstraction applies as well to create a "Mobile view" for your Silverlight application.
Unit Testable
o Silverlight includes a Unit Test framework as well. It can be downloaded here: http://code.msdn.microsoft.com/silverlightut/
Challenges if you are not running IIS 7
o Silverlight does NOT care if you are not running on IIS 6 or IIS 7 or Apache for that matter. This is one feature where Silverlight has an advantage over ASP.NET MVC.
Client Caching
o In ASP.NET Web Forms or MVC, you are caching on the server. Silverlight allows you to cache on the client via Isolated Storage (which can be increased to hundreds of megs if necessary). This allows applications to perform ultra fast without bogging down the hosting server.
CONs vs. ASP.NET Web Forms
Difficult to convert existing code
o Silverlight is a completely different programming platform than either ASP.NET WebForms or MVC. Not only will a lot of the code not convert, you also have to think about the client layer and in most cases a complete re-architecture is needed if you are replacing large modules inside your existing ASP.NET site.
NOT the best SEO out of the box
o Google several months ago started spidering SWF files and adding them to the search engine. I think Silverlight is probably still a ways away here. What you can do for Silverlight SEO is the basic tricks to describe the meta data tags really well around the plug in.
Data access
o Data access in Silverlight is limited to Web Services/WCF/ADO.NET Data Services. You cannot make direct calls via ADO.NET or stored procedures to a database.
Security
o Silverlight runs on the client. A lot of your bits are then roaming in the wild on the internet. Furthermore, some of the data access techniques do not support full WS* standard security. Therefore, beyond certificate based transport security, you are either writing a lot of your own plumbing code or waiting for the next rev. The XAML code is pretty much insecure; not many applications have their Intellectual Property in their UI. In Silverlight, that can be very easily reverse engineered using Silverlight Spy for example. Silverlight, just by nature, is a little less secure than an ASP.NET MVC application. Obviously, you would want to encrypt/obfuscate your Silverlight assemblies before letting them off in the wild.

1. Silverlight can access the DOM from the hosting page and
2. the hosting page can access the Silverlight part.
That's a big + for Silverlight
But all other limitations cry for WPF/Windows-Forms with Clickonce
file access, right mouse click, ease of db access

The pros
The Silverlight plug-in means developers can target a single, consistent runtime for browser-based applications, rather than dealing with the complexity of multiple browsers in different versions. You also get video and multimedia effects that are hard or impossible with pure HTML and JavaScript, though Adobe Systems' Flash has the same advantages.
Execute .NET code without deploying the .NET runtime. The Silverlight plug-in does include a cut-down .NET runtime, but instead of dealing with a large download and the complexities of the Windows installer, the user has a small download of about 4MB, all handled within the browser. In my experience so far, installation is smooth and easy.
Performance is promising. Silverlight comes out well in this prime number calculator, thanks no doubt to JIT compilation to native code, though it may not compare so well for rendering graphics.
Support for Moonlight means there will be an official open source implementation of Silverlight, mitigating the proprietary aspect.
Silverlight interprets XAML directly, whereas Adobe’s XML GUI language, MXML, gets converted to SWF at compiling time. In fact, XAML pages are included as resources in the compiled .XAP binary used for deploying Silverlight applications. A .XAP file is just a ZIP with a different extension. This also means that search engines can potentially index text within a Silverlight application, just as they can with Flash.
Third-party component vendors are already well on with Silverlight add-ons. For example, Infragistics, ComponentOne and DevExpress.
Take your .NET code cross-platform. With Macs popping up everywhere, the ability to migrate Visual Basic or C# code to a cross-platform, browser-based Silverlight client will be increasingly useful. Clearly this only applies to existing .NET developers - I guess this is the main market for Silverlight, but it is a large one. The same applies to the next point:
Uses Visual Studio. Microsoft’s IDE is a mature and well-liked development environment, and since it is also the tool for ASP.NET you can use it for server-side code, as well as for the Silverlight client. For those who don’t get on with Visual Studio, the Silverlight SDK also supports command-line compilation.
Choose your language. Support for multiple languages has been part of .NET since its beginning, and having the .NET runtime in Silverlight 2.0 means you can code your client-side logic in C#, Visual Basic, or thanks to the Dynamic Language Runtime (DLR) Iron Ruby or Iron Python.
Isolated storage gives Silverlight applications local file access, but only in a protected location specific to the application, providing a relatively secure way to get this benefit.
The cons
If Apple won’t even allow Flash on the iPhone, what chance is there for Silverlight?
Silverlight is late to the game. Flash is mature, well trusted and ubiquitous. Silverlight 2 only comes out of beta in the Autumn (we hope). It is the version we care about - the one that includes the .NET runtime - and will still lack support on mobile devices, even Windows Mobile, though this is promised at some unspecified later date.
The design tools are Expression Blend and Expression Design - but who uses them? The design world uses Adobe PhotoShop.
While having solution compatibility between Expression Blend and Visual Studio sounds good, it’s actually a hassle having to use two separate tools, especially when there are niggling incompatibilities, as in the current beta.
No support for the popular H.264 video codec. Instead hi-def video for Silverlight must be in VC-1, which is less common.
It’s another effort to promote proprietary technology rather than open standards.
Yes Linux will be supported via Moonlight, but when? It seems likely that the Linux implementation will always lag behind the Windows and Mac releases.
Silverlight supports SOAP web services, or REST provided you don’t use PUT or DELETE, but doesn’t have an optimized binary protocol like Adobe’s ActionScript Message Format (AMF), which likely means slower performance in some scenarios.
Silverlight is a browser-only solution, whereas Flash can be deployed for the desktop using Adobe Integrated Runtime (AIR). Having said that, yes I have seen this.
You have to develop on Windows. This is particularly a problem for the Expression design tools, since designers have a disproportionately high number of Macs.

You can add to the pros and cons of the usual stuff of the online vs offline debate. Some items:
Pros
wpf(offline):
better access to low level parts of the computer.
cpu usage is local, so you rarely have cpu load issues.
not dependent of the net.
no downtime for maintenance.
silverlight(online):
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
I simplified it a bit, there are gray areas in the list. I only tinkered with XBAP, so that one I'll leave out. The Cons are not hard to figure out after looking to the pros.
HTH

I would consider WPF ClickOnce with sync framework support (www.msdn.com/sync). This would allow you to support limited functionality when the user is not connected to the corporate network (which will eliminate any browser-based deployment scenarios, such as Silverlight and XBAP).

If you don't need all WPF I would try do it in Silvelight first Then you can switch to WPF more easily if you need it later.
Here I think it applies the “less is more” principle: it’s true that with WPF you have much more options and can access to the user computer, but that can finally be more a problem than a help as the times go. Think for example in how many changes you can need to change from Windows XP to Vista in an application that uses a lot of the “user computer” resources!

Mark, what do you mean when saying 'single browser' for XBAP? XBAP does work with Firefox for example. It indeed requires .NET Framework and it is unlikely that we will have WPF in Mono anywhere soon (if ever) so you are stuck with Windows, that's right.

Isn't click once available on firefox these days, via this addon: https://addons.mozilla.org/en-US/firefox/addon/1608