Develop Reference

Making sure my application is Terminal Services safe

Our company uses a system of which I am the sole developer. It is a C# based desktop application that is run on some 50 workstations or so and all connect to one central SQL Server database.
Our network administrator is now looking at presenting the application through Terminal Services, something that I know nothing about, yet.
As I started Googling around I saw that, apparently, some applications do not work under Terminal Services. MS Paint is mentioned as an example. So this got me wondering, what does a developer need to know to make sure that his/her application works in Terminal Services?
I don't have the time right now to investigate TS in depth but I'm hoping there might be an article somewhere that is written for developers. As in "Things not to do when you develop an application that will be run in Terminal Services".

Terminal Service RemoteApp works pretty well if you application is designed to be multi-user compatible. so you will need to ensure user session related data is not shared, but placed in isolated storage with IsolatedStorageContainment set to DomainIsolationByUser for example.
here are some useful links:
http://www.fmsinc.com/microsoftaccess/terminal-services/remoteapp.htm
https://www.youtube.com/watch?v=Nf20-76dMcg
https://msdn.microsoft.com/en-us/library/3ak841sy%28v=vs.110%29.aspx

best solution for architecture of a enterprise web App, that use hardware & local resources & heavy data entry forms

we have an APP, that uses many local resources, such as windows printing API, windows registry, some Active X to connect to POS devices(to pay money & get receipt, the price is sent from APP), Barcode printer to print labels, RFID devices to read & write some data. The application is written with .Net framework 3.5, and uses some new features of .Net framework (e.g.: WCF). The forms in app are very heavy forms(7 of them are essential), in each form, there are over 100 Textboxes, combos, radio buttons, panels & many other controls, that according to need of user are shown or hidden, disabled or enabled, filled & cleared, many many times.
After the user does the work, prints most be sent to previously selected printer automatically, labels most be printed by barcode printer, RFID & POS devices are called if neede.
The problem is that now we need a web base version of this. the reason is that there are an administration department who needs to be aware of any transactions online (there is a dashboard software). In the WIN APP version, we use WCF to send & receive new data (something like replication happens).
According to my searches, there are 3(even 4), way to accomplish this goal, as below.
Using WPF technology
Using Clickonce
Using Pure html + Active X(meaning asp.net, very heavy javascript & Write Active X)
Hosting windows forms controls in IE
WPF’s XBAP is good, but:
It needs to download all dll’s to local machine & then start the application. This also happens every time a new version is uploaded to server. The sizes of dll’s are about 5meg.
Also there is a risk that a user can disassemble the dll’s. Also we need to sign the assemblies in order to be able to use win API’s, and the user need to add the site to its secure site.
The main disadvantage is that WPF is not actually in Web architecture, I mean, dll’s do calculations on client side & the server is only responsible for saving entities (& does some validations).
refer to https://stackoverflow.com/tags/web-applications/info
Clickonce:
No idea at all, we can deploy App(the WPF version or windows forms version) as a clickonce app, but the server is only responsible for updating new versions of software.
Pure web & HTML + Active X:
This is the time consuming work, everything seems to be ok, but actually we need to be JQuery & AJAX masters & I think most of time is spent on debugging javascript. Also only IE can run the App # all, because of Active X controls in page.
Winform in IE:
Not a good choice at all, but we can do this, the output is works only in IE, also the rendered UI, is in very bad style.
There is also another way, may be a hack, when we develop with pure web, we can write some WCF services to do the hardware part(commiunicating with hardware, local resources & other things) & install them on clients(run for example with cassini). So when we need for example to work with hardware & local resources(POS, RFID, Registry & others), we can call them from our site with the web service call(that points to local host).
Which of these are good choice & what?
Is there any other solution?
any idea can help.
many thanks.

Cleanest solution may be to go WPF for the presentation tier (silverlight will require an additional step to access the local machine) and click-once (just because you are considering click-once doesnt mean your server is now just a distribution mechanism, also correct me if im wrong but you can also include the .Net runtime as part of the click-once distribution package)
Also just because its WPF doesnt mean all your business logic needs to be downloaded with the client, id collect your business logic server side, at least the sensitive stuff and call it via wcf -with security of your choice-.
EDIT
Some useful links
Learning WPF with BabySmash -Manually Managing ClickOnce and some more Designer Goodness
Deploying a WPF Application (WPF)
Silverlight, Wpf Web App (xbap) or Click Once? Pros and Cons

I'm not sure I understand all of your requirements correctly. It looks to me that all you need is a service component that tracks the transactions. Rather than rewriting everything as WPF/SL, why not modify your current application (you didn't mention the technology used nor if you can modify it) to log any transaction to a service endpoint.
The service endpoint records the transactions in a database (e.g., WCF over https, storing data in SQL Server). From there you can either expose the information as part of the dashboard software you mentioned, or you can create your own reporting application using something like ASP.NET MVC.

What are the challenges in porting your existing applications to Microsoft Azure?

What are the challenges in porting your existing applications to Azure?
Here are few points I'm already aware about.
1) No Support for Session Affinity (Azure is Stateless) - I'm aware that Azure load balancing doesn't support Session Affinity - hence if the existing web application should be changed if it has session affinity.
2) Interfacing with COM - Presently I think there is no support for deploying COM components to the cloud to interface with them - if my current applications need to access some legacy components.
3) Interfacing with other systems from the cloud using non-http protocols
Other than the above mentioned points, what are other significant limitations/considerations that you are aware off?
Also, how these pain points are addressed in the latest release?

our biggest challenge is the stateless nature of the cloud. though we've tried really really hard, some bits of state have crept through to the core and this is what is being addressed.
the next challenge is the support of stale data and caching as data can be offline for weeks at a time. this is hard regardless.

Be prepared for a lengthy deployment process. At this time (pre-PDC 2009), uploading a deployment package and spinning up host services sometimes has taken me more than 30 minutes (depends on time of day, size of package, # of roles, etc).
One side effect of this is that making configuration changes in web.config files is expensive because it requires the entire app package to be re-packaged and re-deployed. Utilize the Azure configuration files instead for config settings - as they do not require a host suspend/restart.

My biggest problem with Azure today is operability with other OS’es. Here I am comparing Azure to EC2/Rackspace instances (Even though Azure as PAAS offers a lot more than them e.g. load balancing, storage replication, geographical deployment etc in a single cheap package).
Even if you consider me as a BizSpark startup guy, I am not inclined to run my database on SqlAzure (Sql2005 equivalent) since I can’t accept their pricing policy, which I’ll have to bear three years after of the BizSpark program. Now they don’t have an option for MySql or any other database. This to me is ridiculous for an SME. With EC2 I can run my MySql instance on another Linux VM (obviously in the same network. Azure gives you the capability to connect to network outside theirs, but that is not really an option)
2nd. This is again is related to using *nix machines. I want all my caching to be maintained by Memcached. With asp.net 4 they have even given us out of the box memcached support through extensible output caching. The reason why I am adamant about memcached is the eco system it provides. E.g.: Today I can get memcached with persistent caching as an add-on. This will even give me the opportunity to store session data with memcached. Additionally I can run map reduce jobs on the IIS logs. This is done using cloudera images on EC2. I don’t see how I can do these with Azure.
You see, in the case of Amazon/Rackspace I can run my asp.net web app on a single instance of Windows Server 2008 and the rest on *nix machines.
I am contemplating running my non hierarchical data (web app menu items) on CouchDb. With Azure I get the Azure table. But I am not very comfortable with that ATM. With EC2 I can run it on the same MySql box(don't catch me on this one :-)).
If you are ready to forget these problems, Azure gives you an environment with a lot of grunt work abstracted. And that’s a nice thing. Scaling, loading balancing, a lot of very cheap storage, CDN, storage replication, out of the box monitoring for services through Fabric Controller etc among these. With EC2/Rackspace you’ll have to hire a sysadmin shelling $150k PA to do these things (AFAIK Amazon provides some of these feature at additional cost).
My comparisons are between azure and Amazon/Rackspace instances (and not cloud). For some this might seem like apples and orange. But azure does not provide you with instances. Just the cloud with their customized offerings…

My biggest problem is/was just signing up and creating a project. And that's how far it got over the last month.
Either I am doing something very wrong, or that site is broken most of the time.

One important challenge is the learning curve, lack of experienced developers, the time it takes to become productive .
This happens with all technologies, but with the cloud there is a fundamental change in how somethings are done.

If your application needs a database, I'm not sure that Windows Azure has a relational database (right now)
Also, there are other cloud computing providers that can offer you more options in configuring your virtual machine for example, it really depends on what you actually need and want.

Please give reference/guidance to make a web application for managing all IT assest/devices

Please give reference/guidance to make a web application for managing all IT assest/devices .
Application consist of two component Web application and Windows .NET Application.
Client Windows .NET Application scan all active network & find all IT assests like printer,scanner & upload all data into the web application.
Now our team using Asp.net & c#
technology for this project.
Please give suggestion regarding the
client application & web application
interaction.
Suggest any library/reference
required for the project.
Is Microsoft sync frame work good for
client application.
Is Microsoft WCF will be a good
option for client & server
interaction(for making API).
How to scan active network for
finding devices by using client
application.

I will suggest you to go for a simple solution like
1. A windows application that takes care of scanning the entire network of computers from the installed computer and then sends the information to a web service
2. A web service to accept the assets list and then save them to the database
3. An asp.net application to display and catalog the indexed assets.
The part that will become somewhat complicated will be the assets discovery since it should be handled by the windows application. Your best bets are
1. to depend on the windows registry
2. to use the Windows Management Instrumentation (WMI)
3. If you dare you can dirctly program against the Netapi32.dll: NetServerEnum or similar low level win32 API
Hope this will help you to get started

Consider this approach:
Asset Catalog Service (WCF App). Its responsibility is to act as a repository for found assets. The service encapsulates the actual storage (database, etc).
Asset Finder (Winform app). Its responsibility is to scan all active network, find all IT assets and calls Asset Catalog Service to register the device. Asset Catalog Service will reconsile whether a device has not been registered (therefore will be stored), a device have been updated (therefore will be updated) or no change (therefore will be ignored). You may have multiple instances of Asset Finder running at the same time to speed up the discovery process. Asset Catalog Service or another service may be used to keep track the work pool of the asset finders.
The website (Asp.Net Web app). Its responsibility is to visualize the asset catalog. It queries Asset Catalog Service and display the result to the end users.
I can't see any obvious use case for using Microsoft Sync framework.
Unfortunately, I don't have any experience in writing any asset discovery algorithm. Others might be able to help on that point.
Hope that helps.

This is a bit off topic, but I would suggest looking at options from existing vendors that will meet your overall business requirements. Asset detection and management is not a simple task and creating an in-house application to do it is often a waste of time and money that could be better spent on core business needs or other IT support/resources. Purchasing software from an existing vendor will give you a much better solution than whatever you can code up in a week, a month, or even a year. If you are trying to catalog even a medium sized network with over 100 nodes then using an established system could end up being much cheaper than building your own. Here are a few examples of existing products:
http://www.vector-networks.com/components/network-discovery-and-mapping.php
http://www.manageengine.com/products/service-desk/track-it-assets.html
I haven't used either of them, but I have been down a similar route trying to create an in--house server monitoring and management system. We spent two weeks working on a prototype that was eventually scraped for a 3rd-party system that cost $1,000 a year. It would have cost us at least $10,000 to build something with 1/10th the features, let alone support and maintain it. Even just searching for a FOSS solution and then using that as the basis for your project (something like nmap) would be better than starting from scratch.
Best of luck!

Windows based application should be used to scan network and collect info about devices/assets available in the network. save those information in database.
look at following project to get and idea how you may scan the network http://sourceforge.net/projects/nexb/
the same database should be used by ASP .net app to be used for reporting purposes, you may also use it to group/tag/categorize various assets.
Also store scanned devices in separate "departments" depending on their IP schema.

Distributed application (WCF/Remoting/web servervices) Vs Web application

I am making a medium sized standard LOB application. Currently its a web application but I am formulating a proposal to revamp it into a Desktop remote application. By this I mean that the database and the application server will be hosted in a remote location. The client application will communicate with the server via the internet through (either WCF / Webservices / Remoting).
My question is this: The only reason I am shifting this from a web platform is due to the constraints of the web (I dont want to do AJAX or Java scripting to minimize those constraints, so please no JS/AJAX recommendations). I have made traditional desktop applications and they are considerably fast but i have never made a remote or a distributed application. I am not sure weather the speed of the application will be faster then the web or not.
As I understand it, the remote desktop application would be much faster. For one, there wont be any post backs involved, (I hate them so much). The data will obviously come via internet, so in that respect, is it better to shift to the remote desktop just for sheer speed and power?
Any help in the right direction would be greatfull. Many thanks.
Zeeshan

I think biggest advantage of desktop clients over web applications is freedom in UI design, and you don't have to worry about any inconsistencies in the client environment, although those are not an issue if you are using a client that runs on silverlight.
Personally I don't like web applications that requires a lot of user interaction, there are some of them that is a pleasure to use but I think it is very easy to do it the wrong way and end up having a buggy or not so responsive application (probably because of the incompatibilities in browsers, I have IE, Firefox and Chrome installed on my computer and I use one for some websites because they run faster on it, and others for other sites because web pages show up correctly only on them). Though this might not be an issue for a silverlight client.
In case of network speed, depending on the things that goes on the wire even with binary serialization remoting might have quite a bit of overhead. For example along with the data it writes full class names, library names and their versions so it can get pretty big and slow even for small amounts of data (although it should still be smaller then HTTP). It also has the same problems that HTTP has over unreliable connections because it uses a similar protocol. For one project we had to write a custom serializer for some objects because binary serialization alone was generating 200K, but our custom serializer for those objects were generating 50K. Then we ended up writing our own network protocol because the one that comes with the runtime was frequently stalling over unreliable wireless networks, and remoting doesn't give any control on the socket created by it (which makes sense in terms of encapsulation but you can't close it and force it to open a new one).
(I am assuming that you are asking about remoting vs web app. not remote desktop vs. web apps, because of your note about post back, you can't avoid it with a remote desktop session)
Rewriting an application just for sheer speed? No, because probably user won't see much difference in response time.

You are somewhat ambiguous with your terminology - do you want a client app that runs on the user's machine, or do you want an app that runs on the server and the user connects via remote desktop (RDP)?
If you are talking about a client app that communicates to the server via WCF etc., then yes it will be faster than a standard web app, although it will still be slower than a native desktop app. It will be faster than the web app not just because of the lack of postbacks, but also because you will be sending pure data through the wire, not a massive amount of HTML/Javascript combined with your data. With a client app, you have several options so consider them carefully - do you want Silverlight, WPF, or a native WinForms app? Each have their positives and negatives.
If you were talking about having a client app running on the server which the user then access via RDP, then you have other considerations to think of. For any more than two concurrent users you will need to consider buying CALs so the users can connect to the server. At this point you should also be considering whether you should be running a terminal server or Citrix type setup instead of using remote desktop.
Edit
When using WCF over a WAN (internet) you will certainly have to consider how you will secure it. WCF makes it trivial to secure the channel, but you need to consider how you will do authentication - there are a couple of different ways, but you can easily google that stuff yourself. The method you choose will be important due to the limited resources or skill-sets of the users.
As for what you write it in, you can't argue with Winforms if that is where your experience is. Personally, i would never again use ASP.NET/Ajax/etc for a web type application, it would be WPF or Silverlight all the way (i would only use ASP.NET for simple web sites). You can use the express (free) versions of Visual Studio to write it in, you don't need Expression (it's just a nice to have, and is more aimed at the design side than the actual coding side). Deploying the app need not be difficult - Silverlight or WPF xbap are delivered via the web, the user has to do nothing (except for the simple install of the Silverlight plugin or installing the right .Net framework for WPF - check this link). Winforms or stand-alone WPF require slightly more work, but you can avoid most issues by writing a good installer.
Whichever you choose, make sure you don't under estimate the time for development (because you will have a bit of a learning curve), and also make sure you budget enough time for testing it - especially the security side of it :)

I have been in a similar situation, although started with a Winforms LOB application.
Heres what we found with WinForms...
It's going to be harder to deploy in your release cycle, to all client machines.
WinForms can't be run on other operating systems easily. (with the exception on mono)
WCF endpoints can get complicated, and you need to manage an endpoint for release/version of your application.
Authentication, Authorization and Security can be tricky to get right!
Heres why you should stick to a html web application.
it's going to be easier to deploy, as you just need to copy one set of DLL's into the bin folder. Can be scripted from a continuous integration or staging server.
Security is going to be easy, by using a SSL certificate.
Silverlight/Flash should fill in the gaps that HTML leaves out.
Microsoft has also combined the connected systems in .net 3.5, they now call it WCF (ASMX/Remoting/etc...). It's got quite a learning curve 4-5 weeks.