Is it possible to check via web site if end use has installed .NET Framework4 Client ?
It's desirable if this way doesn't use any plugins (flash or silverlight).
From the server side, the best you can do is sniff the user agent that is sent with the request to the website. In it you'll usually see something along the lines of:
.NET <version number>
Or something to that effect.
Of course, there are major drawbacks to this (as there is with any user agent detection) which warrant not doing this:
The user agent can be spoofed
Parsing strings that are not structured is generally error-prone
Not all browsers (i.e. non-IE browsers) are obligated to send this information
That said, ChrisF's comment asking why is somewhat relevant, in the sense that you are better off having code execute on the client side to detect this, as there are more definitive ways (checking the registry) of determining if .NET 4.0 is installed on the client, using mechanisms that you just don't have available to you from the server side.
The thing is, if the code is served up from the server side, then it will probably be sandboxed in some way, and you'll have to figure out a way to access the registry (which is typically restricted in most sandboxes for code downloaded from the web).
Related
I have a vb6-mysql client-server desktop application which is distributed as a setup file.
It uses DLL all logical operations as well as database operations. The EXE and the DLL are installed in the server as well as the client machines. When I say server which only means the database resides in that machine no other difference in EXE or DLLs.
As all the database operations are done in the DLL when connected from a client machine, performance would be less. It is not possible now to change all the logic into database.
Is it possible to store the DLL in the server machine only and use the same DLL by the client machine also so that database connection will always be from the server itself?
Is converting the DLL to a windows service the possible solution for this?
How can I to convert it to a service?
And finally, if it is possible to make the DLL act as a service, what would the connection issues be?
You appear to be trying to rediscover n-tier application development.
The usual way this would be done using VB6 within a LAN would be to create an ActiveX EXE instead of a DLL so you can use DCOM. However DCOM isn't something you'd want to expose over the Internet.
For such cases it is more typical to use a commonly-open-port protocol such as HTTP or HTTPS. Almost everyone has firewall settings permitting outbound HTTP and HTTPS connections and most of the major Web servers undergo regular hardening to make them safer to expose to the Internet.
The classic way to do this with VB6 was to use IIS to host the Remote Data Service, which uses a form of Web Service "under the covers" where your program doesn't deal with the gory details. However this is a deprecated approach, and today configuring IIS and the RDS components can be a chore since they are locked down hard by default.
This leaves you with such things as the deprecated SOAP Toolkit or 3rd party tools such as those in the PocketSOAP suite... or you can roll your own.
Doing this from scratch can be a bit of work but is more flexible, allowing REST instead of SOAP which can have advantages in itself. You could use whatever Web server you choose that can work with VB6 (via CGI, etc.).
The hardest approach to justify might seem the simplest on the surface: create your own protocol over TCP and write a Windows Service. This can be the most flexible of all but it can be more work than other options and you are on your own as far as making it and keeping it secure. You'll probably also face firewall issues depending on where your clients are and what the local firewall policies are there.
When we could rely on DCOM the issues were relatively small aside from security configuration headaches. With the Internet in the picture it is an entirely different story.
This really isn't something you undertake casually. Even assuming that your database is safe exposed to the Internet is naive and should be rethought.
I'm in the process of providing a Web UI as an alternative to our current desktop UI for our C/S enterprise application.
When developing the client-side in our desktop version, UI developers could connect to any server so they only needed the client-side environment.
When developing a Web UI (Client-side JavaScript in the browser), we are bound by the browser's "Same origin policy" so the UI must talk to the same server from which the UI code is downloaded.
As far as I see it till now, the development scenario for the UI guys is:
Developer installs server on local
machine and runs it.
Developer edits the HTML+JS+CSS files on local installation.
Developer has to reinstall/update server on local machine each time there's a need to test UI code against new server behaviour.
This does not seem too comfortable, at least compared to our previous C/S style development.
Are there any other ways you can suggest to that will not require UI developers from installing and updating server side components on their development machine ?
Or anything else related that can simplify the development process ?
Thanks :-)
Editing in some clarifications:
I'm mostly interested in the aspects of UI coding, not UI design.
I need a lot of server interaction - getting data from RESTful web services, which are developed in parrallel - hence the need to have an up-to-date server
You haven't specified the development platform.
As far as pure HTML/JS/CSS is concerned, you don't need a server. The UI developer can fine tune UI components locally.
The moment you want to talk/integrate to Server (via AJAX, JSP, ASP...) then you need to connect a development server as now your changes have to be served by Server.
Most of UI fine tuning can also be done from Firebug
In our office when changes to styling are required we save the page as a local copy and send it to the UI designer, he makes his changes and we integrate them. So the UI designer don't have to maintain a development environment.
JSONP lets you work around the same-origin problem (with server support) -- check it out! If the front-end-in-the-browser developers are using a good framework suc as jQuery or (my favorite) Dojo, JSONP should be no harder for them than plain JSON.
Develop on a shared server, but depending on the size of the team.. that's challeging with respect to version control.
Or deploy automatically generated virtual machines with nightly builds, so the devs don't have to install, but always use a recent version.
In the case of UI developers depending on a common REST server, the UI development can be done on the local machine and the REST service should be on a central server. When changes are made to the REST service these should be deployed to the central server (when stable), so all developers can use the newest version (this also helps with testdata).
You could try using a proxy on the developer's machine where some paths redirect to the server and some paths redirect to local folders.
Hmm, I actually didn't really get any information on what kind of technology you're using. If - with UI Developers - you mean designers, which have to take care about the CSS, layout etc, then we do it the same as lud0h said. We (developers) send the UI designers a copy of the server-side produced HTML pages. They then edit the HTML pages according to accessibility guidelines, CSS and layout and send us back the outcome of their work. We use their HTML pages then for integrating them in our web applications.
If you don't just mean tuning CSS, but also to write JavaScript / Ajax functionality you HAVE to use a server with which you're communicating. As you said, normally this is done by having a local environment which is similar to the server-one. In .Net Visual Studio '08 provides an internal webserver, alternatively you have to install IIS locally. In Java environments you have to install Tomcat and related technologies. In my eyes this is a must. What you have to have is
Versioning system (CVS, SVN,...) where developers commit regularly (minutes/hours)
local environments where developers checkout the source from the repository and develop
Test server where you deploy on a daily basis (could be like daily builds) in order to test your running product
I guess this should be what a professional development environment should consist of. The difference to C/S application development is that web UI and web-client code are not that separable as a Client UI in C/S environment from the server-side. Unless you develop with technologies like GWT or Silverlight which are quite similar to C/S, just running inside the browser, but communicating over RPC calls or web services.
//Edit:
What I nearly forgot. Don't do something like developing on the server directly, meaning that all of the developers access the server's filesystem where the code, UI etc. lies!!
You can use CORS. a new technique just like Ajax, but with ability to make calls on other domains. so you will need only one UI on one server. think this can help you.
I'm part of a distributed development team. We all work through terminal services, accessing a remote server where our applications are located.
We're working on a project in which a client application consumes a WCF service, which exposes all the business logic functionality.
In our development process, a developer is often asked to develop an entire use case from user interface to database access, including the service and the business logic.
In such cases the developer must be able to debug the functions/methods on the server side that she/he has build for a given use case. The problem with that is that the service must be run and when another developer needs to debug his/her work, an exception is thrown (I think it is 'AddressAlreadyInUseException' not sure) and the 2nd developer is not able to perform any kind of debugging at the service. This happens even thought we (off course) have different windows usernames and hence we are working in different sessions.
It's still possible for the client app. to continue working with the 'original' service instance since we're catching the exception at the service, but debbugging is impossible. And if the first developer stops the wcf service then the app. fails.
I would like to know if you could have any recomendation for us. My be there's some sort of tool available (even if we must pay for it) that could somehow isolate each developers' workspace at the server... or may be we just need to change something in the way we work.
I would be very grateful for any kind of advice or clue.
Best regards,
Gonzalo
I would recomend that each developer had their own copy of the server services.
When we develop, each developer has a full environment on their machine. As things are completed, they are checked in to the version control system. When the other developers get the lastest version, new functionality is spread to the other developers.
If I understand your setup, all developers are working against the same server, in this case a programming error of one developer will stop all development.
Hey man, the debugger connects through IP communication. That means if a service or process binds a listener, no other service or process can bind this IP port a second time.
That is the reason for throwing the exception.
In Citrix you have the Virtual IP configuration.
You can also consider to place a VM on the server that serves only for one developer. This would also solve this problem
A little background -- we're designing an application that uses a client/server architecture consisting of:
A server which loads server-side modules, potentially developed by other teams.
A client which loads corresponding client-side modules (also potentially developed by those other teams; each client module corresponds with a server module).
The client side communicates with the server side for general coordination, and as well as module specific tasks. (At this point, I think that means client talks to server, client modules talk to server modules.)
Environment is .NET 3.5, and client side is WPF.
The deployment scenario introduces the potential to upgrade the server, any server-side module, the client, and any client-side module independently. However, being able to "work" using mismatched versions is required. I'm therefore concerned about versioning issues.
My thinking so far:
A Windows Service for the server.
Using System.AddIn for the server to load and communicate with the server modules will give us the greatest flexibility in terms of version compatability between server and server modules.
The server and each server module vend WCF services for communication to the client side; communication between the server and a server module, or between two server modules use the AddIn contracts. (One advantage of this is that a module can expose a different interface within the server and outside it.)
Similarly, the client uses System.AddIn to find, load, and communicate with the client modules.
Client communications with client modules is via the AddIn interface; communications from the client and from client modules to the server side are via WCF.
For maximum resilience, each module will run in a separate app-domain.
In general, the system has modest performance requirements, so marshalling and crossing process boundaries is not expected to be a performance concern. (Performance requirement is basically summed up by: don't get in the way of the other parts of the system not described here.)
My questions are around the idea of having two different communication and versioning models to work with which will be an added burden on our developers. System.AddIn seems quite powerful, but also a little unwieldly. (I'm also unsure of Microsoft's commitment to it in the future.) On the other hand, I'm not thrilled with WCF's versioning capabilities. I have a feeling that it would be possible to implement the System.AddIn view/adapter/contract system within WCF, but being fairly new to both technologies, I would have no idea of where to start.
So... Am I on the right track here? Am I doing this the hard way? Are there gotchas I need to be aware of on this road?
Thanks.
This sounds too complicated. Consider an architecture where each added module includes both the client side code (use System.AddIn if you like), but where the server side module is a new service.svc file. The client would know the URL to the corresponding service.
Alternatively, you should look into Microsoft Extensibility Framework (MEF) for the add-in feature. That's what they'll be starting to use for Visual Studio extensibility in the coming release.
I've created a service for one of my apps. How do i create a system tray component in VB.net that can be used to monitor the progress of the service? Is there a way to have this installed via tcpip on multiple client machines such as those that are for our employees?
We do exactly that here, with the server running a really basic HTTP server on a configurable port on a separate thread that returns status in an XML format (nothing else, just that) -- the client just uses a web request to get the XML, before parsing it and displaying it appropriately.
This approach also allows for future extensibility (detailed status, sending service control commands, adding an association to an XSLT file elsewhere for use with a normal web browser, etc.)
You could use WCF for this. Using WCF your service would open up an EndPoint which would expose status information to callers. You could then build a tray icon application that can be deployed to the employees workstations. The tray icon application could periodically poll the WCF service the your Windows Service is hosting and get status information. I know #Johan mentioned Remoting already and this is a similar approach. I'd recommend WCF though as the programming API is more simple, IMHO, and WCF will give you more flexibility with regards to network transports, etc.
I guess your question is not about how to actually do the "traybar"-thing, but how to communicate with the service to get the information you want to show in the monitor/traybar-program?
It can be done in many ways, API is one way, use sendmessage/postmessage/getmessage is one way to make 2 running programs communicate with each other without having to store anything in files or databases first.
DDE is another way. If it needs to do the stuff via net then there is something called NetDDE, but I havent done anything with NetDDE I cant help anything there.
But about the API and DDE, feel free to ask more questions if you want some clarification.
I'll take the second question: Is there a way to remotely install software on client machines?
Yes. However it is very dependent on your environment. For example, if you have an Active Directory domain, you can use group policy to force installation of software on the client boxes.
If you don't like that or if you aren't on active directory, you can buy something like Altiris to push installs down.
Another option would be to use login scripts which would run a custom program to detect if your program is installed and take appropriate action. But then you are probably better off buying Altiris.
For the comunication part, i have used remoting before, and this works very well. With a little bit of configuration, you can even get it working to another machine.