CRM without silverlight RRS feed

  • Question

  • Previously when we have developed CRM solutions they have often been done in silverlight. However, as silverlight looks like it's going to disappear, we want to move away from that. So what are the best non silverlight solutions for CRM development. We have tried Ajax, php and web services and they work and work well but they do not integrate well into a solution which creates a problem for deployment.

    So what's the best non silverlight solution?

    Tuesday, February 17, 2015 12:16 PM

All replies

  • That sounds like a strange statement to me. Silverlight is a vehicle for your UI. HTML/JS/CSS would be a different vehicle for your UI. Why you do you have a fundamental problem with switching between them? NB. There are other alternatives too, such as OneClick deployed WPF, etc. but the same question applies.


    Tuesday, February 17, 2015 12:20 PM
  • We can switch between silverlight and HTML/JS/CSS with no problems but the latter are all client side technologies what we want to use is something like AJAX or web services that the client can connect to. I have found no way to include the server side element of the AJAX requirement or a web service in a CRM solution.

    As long as the requirement is fairly minor then it is no problem to implement it in jQuery or something similar at the client. As the complexity grows it makes more sense to implement it at the server. Ideally what we want is a non silverlight solution which can be deployed on any CRM site without having to do anything more than install a solution.

    Tuesday, February 17, 2015 12:54 PM
  • Re 'We can switch between silverlight and HTML/JS/CSS with no problems but the latter are all client side technologies '.Silverlight is also a client-side technology, and so is AJAX, so HTML / AJAX / JQuery are all alternatives to Silverlight

    If you want to develop and deploy web services that can be called from any of these client-side technologies, then ASP.Net would be the answer in the Microsoft world. However, CRM provides no mechanism to deploy any such server-side components in a solution, so you'd have to deploy the ASP.Net web services using .Net tools

    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Tuesday, February 17, 2015 8:18 PM
  • I'd challenge, 'As the complexity grows it makes more sense to implement it at the server' but how are you making your server calls with Silverlight now?



    Wednesday, February 18, 2015 11:26 AM
  • We use pretty standard Odata / REST calls. That is fine for accessing the data but we want to avoid the overhead of exchanging vast chunks of data back and forth between server and client which is necessary if we have a wide spread change to the database. For example if I want to add 10% to all product prices for all products in one branch of a product hierarchy that is something which is quite simple to do at the server by sending an AJAX call and allowing it to update the database in its own time and update the client asynchronously. If I try to implement that in client side logic, whatever the language, it's a lot of work and a lot of data exchanged unnecessarily. Silverlight is not unique in having that problem but the gradual deprecation of silverlight has brought the issue to the fore.

    Wednesday, February 18, 2015 1:08 PM
  • The part I find confusing is that you have talked about client without making a distinction between fat/thin clients so I can see what you mean now. Again, this doesn't effect if it's Silverlight or not. If your code worked as a fat client implemented in Silverlight then it would work as a HTML or OneClick WPF client. However, equally, if your code works a thin client in Silverlight then again, it will work well in the other UI technologies. So lets drop all this talk about technologies and concentrate on if you want a thin or fat client.

    Let's start with networks, what is data access comms like, do you need to work offline?


    Thursday, February 19, 2015 8:21 AM