|
All passwords disappear after cleaning Windows.
Thanks.
Lubos
|
|
|
|
|
How can I create ASMX Web Service in asp.net C#
modified 11-Apr-17 10:59am.
|
|
|
|
|
Member 10291661 wrote: Any Idea ?
Yes. Do your own homework.
We do not do your homework: it is set for a reason. It is there so that you think about what you have been told, and try to understand it. It is also there so that your tutor can identify areas where you are weak, and focus more attention on remedial action.
Try it yourself, you may find it is not as difficult as you think!
If you meet a specific problem, then please ask about that and we will do our best to help. But we aren't going to do it all for you!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I have change my question, its not homework, i am learning Web Service and try to make Stock exchange project..
So I am asking how can I create ASMX Service in asp.net C# and how to access from Web application?
|
|
|
|
|
|
Message Closed
-- modified 30-Apr-17 23:58pm.
|
|
|
|
|
Read what I said.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Message Closed
-- modified 30-Apr-17 23:56pm.
|
|
|
|
|
Actually, you did ask me.
You used the "Reply" widget on one of my posts, not his. Check the indentation / parent message line...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Do you have a specific question?
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
"asmx" is "legacy" technology.
Unless you want to be "obsolete" right from the start, you should read up on what is "current" in terms of REST (and web services) for "new" development.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Have you got the things done? If yes, please share.
|
|
|
|
|
I have the following code:
private void AddService()
{
MyService service = new MyService();
_services.Add(service);
service.StatusChanged += Service_StatusChanged;
AddStatus(string.Format("Service '{0}' created", service.ServiceId));
var newTask = Task.Factory.StartNew(() =>
{
service.Start();
}, service.CancellationTokenSource.Token)
.ContinueWith(task =>
{
switch (task.Status)
{
case TaskStatus.RanToCompletion:
AddStatus(string.Format("Service '{0}' completed", service.ServiceId));
break;
case TaskStatus.Canceled:
AddStatus(string.Format("Service '{0}' cancelled", service.ServiceId));
break;
case TaskStatus.Faulted:
AddStatus(string.Format("Service '{0}' errored", service.ServiceId));
AddStatus(task.Exception.ToString());
break;
}
App.Current.Dispatcher.Invoke(() =>
{
Services.Remove(SelectedService);
SelectedService = null;
});
_services.Remove(service);
AddStatus(string.Format("Service '{0}' removed", service.ServiceId));
});
}
Towards the bottom is a section called "Remove the service". This removes the UI model from the list and removes the service class from the internal list of services.
If the Task.Status is RanToCompletion or Canceled, the the remove code works fine. However, if Task.Status is Faulted then the UI portion inside the Invoke doesn't work. It hits the
Services.Remove(SelectedService);
SelectedService = null;
but doesn't actually remove the model.
Anyone know what's wrong?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Did you tried like below?
case TaskStatus.Faulted:
_services.Remove(service);
AddStatus(string.Format("Service '{0}' errored", service.ServiceId));
AddStatus(task.Exception.ToString());
break;
modified 20-Sep-20 21:01pm.
|
|
|
|
|
No, because that's not the problem.
The _services collection contains instances of the services. The "Services" collection is an ObservableCollection<servicemodel>. It's this collection that is giving me the problem.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I looked different section sorry.
modified 20-Sep-20 21:01pm.
|
|
|
|
|
For continuations, I find it best to use the explicit continuation that suits that particular status. So, your tasks would look something like this:
Task task = Task.Factory.StartNew(() =>
{
service.Start();
}, TaskCreationOptions.LongRunning, service.CancellationTokenSource.Token);
task.ContinueWith(antecedent => { AddStatus(string.Format("Service '{0}' completed", service.ServiceId)) }, TaskContinuationOptions.OnlyOnRanToCompletion);
task.ContinueWith(antecedent => { AddStatus(string.Format("Service '{0}' cancelled", service.ServiceId)) }, TaskContinuationOptions.OnlyOnCanceled);
task.ContinueWith(antecedent => {
AddStatus(string.Format("Service '{0}' errored", service.ServiceId));
AddStatus(task.Exception.ToString());
}, TaskContinuationOptions.OnlyOnFaulted);
task.ContinueWith(antecedent => {
App.Current.Dispatcher.Invoke(() =>
{
Services.Remove(SelectedService);
SelectedService = null;
AddStatus("Removed from the dispatcher");
});
_services.Remove(service);
});
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: For continuations, I find it best to use the explicit continuation that suits that particular status.
OK. Why? What benefit does it provide? Your example doesn't seem to do anything different than what mine does, unless I'm just not seeing something.
Also, this change doesn't solve my issue.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
To answer your questions back to front - did you read the code comment in the last task continuation? This one: // If you haven't reached this point, then you don't have a current App Dispatcher.. If you don't see the message immediately after, it means your App.Current.Dispatcher has gone.Kevin Marois wrote: What benefit does it provide? There are a few reasons I prefer this approach. Here are some of them:
- I can have my tasks attached to different schedulers - some of the stuff I deal with uses very complex scheduling.
- I'm not mixing code. Each continuation has a single responsibility
- This makes it very easy for me to provide general purpose continuation handlers - for instance, I could have a single OnlyOnFaulted handler that any Task calls.
- This reduces the cyclomatic complexity of your code
Here's an example of the last point
public static class TaskExtensions
{
public static void OnFaulted(this Task task)
{
task.ContinueWith(()=>{ }, TaskContinuationOptions.OnlyOnFaulted);
}
} Calling this becomes as simple as
Task.Factory.StartNew(()=> { }).OnFaulted(); Granted, a single use of this doesn't do much but when you have multiple calls of the same type, this makes things a lot neater.
This space for rent
|
|
|
|
|
Excellent explantion. Thank you. I'm still fairly new to Tasks/threading, so I like deep explantions.
As far as the Dispatcher goes, no I'm sorry I totally missed that comment. So how to I solve my issue of reaching back into the UI?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
BTW, this doesn't compile:
Task task = Task.Factory.StartNew(() =>
{
service.Start();
}, TaskCreationOptions.LongRunning, service.CancellationTokenSource.Token);
I get
Delegate 'Action<object>' does not take 0 arguments
If I remove the "TaskCreationOptions.LongRunning" part then it compiles.
Not sure what's wrong here.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Pete O'Hanlon wrote: // If you haven't reached this point, then you don't have a current App Dispatcher...
OK, so I now have
Task task = Task.Factory.StartNew(() =>
{
service.Start();
}, service.CancellationTokenSource.Token);
task.ContinueWith(antecedent =>
{
AddStatus(string.Format("Service '{0}' completed", service.ServiceId));
}, TaskContinuationOptions.OnlyOnRanToCompletion);
task.ContinueWith(antecedent =>
{
AddStatus(string.Format("Service '{0}' cancelled", service.ServiceId));
}, TaskContinuationOptions.OnlyOnCanceled);
task.ContinueWith(antecedent =>
{
AddStatus(string.Format("Service '{0}' errored", service.ServiceId));
AddStatus(task.Exception.ToString());
}, TaskContinuationOptions.OnlyOnFaulted);
task.ContinueWith(antecedent => {
App.Current.Dispatcher.Invoke(() =>
{
Services.Remove(SelectedService);
SelectedService = null;
AddStatus("Removed from the dispatcher");
});
_services.Remove(service);
});
}
In my Service class to test the faulted state I do a
throw null;
Both the ContinueWith for OnlyOnFaulted AND the code inside the Dispatcher are being hit, yet the Services.Remove doesn't remove the item.
As far as the "If you haven't reached this point, then you don't have a current App Dispatcher..".... my code DOES reach that point even when faulted.. the Services.Remove just doesn't remove the item.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 11-Apr-17 12:02pm.
|
|
|
|
|
The other thought that occurs to me is that SelectedService isn't what you think it is - you're going to have to put a breakpoint on the line you're removing it and see what it is. If it's not the instance that's in the list, you're not going to be able to remove it.
This space for rent
|
|
|
|
|
You know what, you're right. I changed this
Services.Remove(SelectedService);
to
var serviceModel = Services.FirstOrDefault(x => x.ServiceId == service.ServiceId);
Services.Remove(serviceModel);
and it works
Thanks Pete!
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
You're welcome. Glad you got it sorted.
This space for rent
|
|
|
|