I am developing an application in asp.net mvc where i need to have Chat application intergrated in the web page. The chat application should be able to support group chat, private chat, simple file transfer and user should be able to create their own rooms.
Can u people tell me where i can buy a simple chat application with above functionalities. I need it immediately.
or
you could just suggest how to create my own application. The technology to use or just any idea to start.
As i said, i need this immediately, buying asp.net chat application with above functionalities is the best option.
and most important i should be able to integrate chat application in my existing MVC project. We are using ASP.NET MVC, Microsoft SQL Server 2005, Linq To Sql as database interaction tech and C#.
I wouldn't expect to find many commercial options for ASP.NET MVC based chat rooms, since platform is still quite young, plus most buyers would be able to use an "old fashioned" ASP.NET chat application (which is already widely available).
If you need something now, and you are willing to pay, I would say: buy an ASP.NET Forms chat and do a bit of plumbing to make it work against your user repository etc. I know of CuteChat, which is capable of doing this kind of integrating, but many components are likely to provide this feature.
Should you decide to build a chat application yourself - something that does not sound like a viable solution for something you need immediately - you might want to have a look at the AspComet library, which provides a service layer on top of ASP.NET to help you use COMET techniques (long polling etc).
If you need it "immediately" writing your own is pretty much out of the question. Creating a reliable chat service from the ground up takes time.
Pure ASP.Net (technically HTTP) chat services are highly unreliable. Even Facebook's and Google's HTTP chat clients despite their best efforts still have their issues. What you should be looking for is a Flash/Silverlight control of some kind.
If you're willing to forgo the file transfer capabilities there are a myriad of IRC clients that are capable of everything else you mentioned and IRC Servers range from cheap to free.
Related
I'm new to the .net application. am trying to develop an application for Accounting Purpose. Am totally confused that how can I use the design pattern, MVC is preferred. I have to use this app both in Desktop and as a mobile app. App should be more secure.
So please guide me how to design the project. Can you please suggest any examples?
WebApi + MVC is good option I think but for this, should I create 2 solution for both API and MVC?
should it work smart phone as well as desktop?
Database-PostgreSQL
Application will have two parts:
Part I – Accessible to the client through the web page
Part II – Back-end accessible only to us (Company) where all the processing is carried out. Perform the initial setup once the client is registered – create the account in the accounting software and create the chart of accounts
Review and process documents
Accounting – the entries will be passed in the application and will be exported to the accounting software
First of all you can find many tutorials out there on the web about creating a ASP.NET MVC project with Web API.
This can be achieved in one solution as you will see in tutorials.
Example: Getting started with ASP.NET Web API
For the desktop and mobile support, I would like to refer to use Responsive Design. Using a library like GetBootstrap you can create websites that change their content dynamically for each type of device ( desktop / tablets / smartphones / ... ).
Now-a-days everything is mobile. So if you are developing something both for Web and mobile app, API has to be the first and only choice.
The reason behind is that--- More or less what Web shows, APP should also show that, but the layouts or UI are different(here comes the client-side). Moreover if APP needs some extra API, I do not think, that would be much overhead if certain extra APIs are written for the APP. Essentially One API codebase suffices both the paradigms.
It is always a good idea to seperate Client-side architecture with server-side architecture.
I would suggest to seperate the client and server(API), and that would be in best of interest.
Your .net application may serve as client side with MVC pattern where M can call API services and C as usually manages the business logic and V displays the results.
You can write API services(server/backend) in .net, nodeJS, PHP, GO any technology which can manage talking to servers. There also you can create certain architecture or flow of your requests.
Hope that helps
I am new to WCF and going through tutorials right now. I was wondering what are the benefits and disadvantages of using a WPF or an ASP.NET web application as a client for a service. I understand it will depend on the kind of service, but besides the common difference of one being a windows app and other a web application, what are the advantages of one over other.
First of all, the choice of client technology does not depend at all on the kind of service you will be talking to. Both WPF/Winforms and a Web app will be perfectly capable to talk to a web service.
Instead, choice of client technology should purely be driven by requirements on the client side
Factors that you should consider when coosing one client technology over the other are:
Know-How available to you (and your team)
Deployment scearios: How do you get your app to the users, etc.
Client environment: How many OSs do you need to support, how many different browsers would you have to support when doing a web app?
Do you have occasionally connected scenarios, or do you need privileged access to client resources? - This would tip the scale somewhat towards a Rich client.
Even so, in many cases a web app appears to be a very valid option as you have access to a wealth of non-MS tech like Javascript Frameworks, CSS resources etc. etc.
On a personal note: Do not use WCF to define your web services - there are fantastic Open Source Frameworks, most notably ServiceStack that will make you more productive and concentrate on what your service does and less on the mechanics and abstractions.
Are there any good books or websites on this subject covering subjects like:
different migration scenario's (big bang, module for module, function for function) pros and cons
do's en dont's
tooling
handling customer expectations
We have a rather large winforms based product which we would like to migrate to the web. Migrating in a 'big bang' scenario would probably take at least two years. We're looking for alternative scenario's.
I'm especially looking for ways to handle the inbetween scenario, what options do you have to keep customers happy.
Let them use the windows application at the same time as the new web
application?
Let the windows application use the new features from the web
application via a service interface?
Accept the cost of double maitenance for a while to keep customers happy?
You are more likely be doing a complete rewrite. Because web is conceptually different from windows forms, there would be a lot of changes.
Your best bet is stop new development on windows forms app. Start writing a new app for the new features. Then start moving one isolated feature at a time to web.
You have two options for the UI
webforms - matches closely with windows forms model. If you are
using any 3rd party controls like devexpress, you can find the
equivalents in webforms.
mvc - It is more like re-architecting the whole presentation layer.
If your UI layer is already separated from business layer, then it
would be a good choice to go down the path of MVC. However the
development experience is totally different from doing windows
forms.
State
Maintaining application state is comparatively simple in windows
forms. In webforms you have viewstate to do that for you. But you are going to run in to rude shocks as you run into limitations of viewstate, especially when it gets too large.
In MVC, you are completely responsible for maintaining the state.
New skills
You require new skills to mimic state-full scenarios
Strong understanding of javascript, ajax, at least one javascript
framework like jquery. 3rd party commercial tool kits can ease some
of these pains.
Depending on complexity you might need web application frameworks
like Backbone.js /Knockout
Expectations
It would be very expensive to achieve the same responsiveness as windows app, as you will be messing with multiple technologies. Probably your users are going to hate the new app initially. Having skilled web designers on staff is very important
Based on our own experience with moving applications from desktop to web: carefuly inspect the architecture of your winforms applications and if possible - try to provide a web interface at the service or persistence level so that your windows applications use web services instead of directly talking to the database. Then you can let your users launch desktop modules from the application server using clickonce.
Such approach let us move to web quickly and users got the same GUI and a new way to access the application. In fact, it took like 3 or 4 months to redesign existing applications so that they use web services.
Then, we were replacing modules one by one, implementing them as web applications and maintaining both (clickonce and web) for a short period of time so that users were able to get used to new modules.
The migration of consecutive modules from clickonce to web was prioritized in an obvious way - we've started from modules that were used by most users. In fact, the initial release of the system has only one web forms module ready and remaining modules are being replaced for over 2 years now, one by one.
I have a requirement for web application developed in asp.net which allows users to make voice calls among each other from the website.
I have looked at api of skype but it seems more inclined towards desktop application. IS there any api which supports for web application like gtalk etc.
Which technology could be best used for developing such kind of applications? Any input, references would be helpful.
I did read that jabber is underlying technology for gtalk. Does jabber support voice calls, and would it be useful for my situation?
If you can include Flash, it has API for that job, but for client side layer only... probably you can chose java/.net for server side.
The only solution here is flash. Gmail / Gtalk requires the user to download a plugin for it to work, so technically it is a windows application being called from a webpage.
I recommend flash and asp.net for the backend, as said above. Either that or if you are OK with deploying plugins, you could go that route. I wouldn't recommend it unless it is internal only.
I've just been tasked with building a web application using ASP (.net) and am looking for some advice on where to start. In a nutshell the application needs to be able to.
Handle user verification / authentication
Handle sessions
Do SOAP messaging
The application is intended to act as a front end for system functions that are accessible via web service calls.
I intend to do a lot of work on the client side using JavaScript and am thinking of using ASP solely as the framework for the 3 items I listed above.
Appreciate any suggestions you may have.
Use Visual Studio 2008 if you can. Its support for Ajax client libraries and javascript intellisense is very good. (Check out the jQuery add in)
ASP.NET has built in Login controls (and the membership services mentioned by ChrisE), and also has Forms Authentication. Try to leverage these existing components and avoid using session to store user specific objects/data.
---session rant
Its sometimes unavoidable, but you should avoid it whenever you can. It incurs a burden on the webserver for each user, and that leads to some very difficult scaling problems. The FormsAuthentication Ticket has a value property that you can store about 4K worth of user data in - try to use that instead.
---End session rant
Try to use a MVC approach (not necessarily an ASP.NET MVC), but at least one that seperates your presentation / view layer from the data / model layer.
Create a default theme and use it. Most sites will need to have multiple themes later, and refactoring that will be a PIA.
If you need SOAP to interact with Non-.NET services then by all means use it. If you are only connecting to .NET services then look into WCF clients and services. They will give you more flexibility.
If you are doing the client work in javascript, then dont use the update panel. It adds lots of overhead.
Get FireFox + FireBug + YSlow, and IE8 (yeah its beta still). They will help you when dealing with the client end of debugging / styling.
Take a look at the rules for website performance, but take these with a grain of salt. They are intended for very large sites, and some of the items may not be applicable (CDN, DNS lookups, Redirects).
WCF for Soap -- I would also suggest picking this up:
alt ASP.NET 3.5 http://ecx.images-amazon.com/images/I/518N8vYWf1L._SL500_AA240_.jpg
This book is in tutorial form -- and Jesse Liberty is a great teacher (as are his co-authors).
ASP.NET provides out of the box authentication/authorization through the SqlMembershipProvider and SqlRoleProvider classes, or you can use the ADMembershipProvider along with a custom RoleProvider to authenticate and authorize against an Active Directory setup.
Session handling is readily provided by ASP.NET as well, through an in-process server, an external StateServer service, or through a connection to SQL Server (and of course, you can provide a custom Session service if you need something different).
As Lou Franco mentioned, WCF provides the framework for the SOAP calls, and will blend in with your ASP.NET application quite handily.
If you are using ASP.NET Web Forms then for handling user authentication/verification I'd recommend ASP.NET Membership services http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx because it does some of the heavy lifting for you and also helps you from making any elementary security mistakes.
This is not directly related to your requirements, but I'd suggest you study the differences between Web Site and Web Application. The sooner the better. Everything will go smoother if you understand how the project is managed.
You can start here: http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx