I am trying to display some text using MessageBox.Show as shown below in a page_load event in ASP.NET. Before anyone jumps on the case why I am using it in ASP.NET, the use is for debugging only on my own dev box for a special need. There's a reference to System.Windows.Forms in the app.
I used it a few years ago so I know WinForm's MessageBox works. I am using .NET 4.0 and VS 2010. I don't think anything related to this function has changed.
MessageBox.Show("Message", "Caption", MessageBoxButtons.OK, MessageBoxIcon.Information, MessageBoxDefaultButton.Button1, MessageBoxOptions.DefaultDesktopOnly); //used also ServiceNotification option
Any ideas why the message box doesn't display? I have only that line in the code.
ADDITION:
I am VERY AWARE of the message box thing implications. It's a temporary thing for debugging only. The line won't go into production. I have no access to javascript. Please put your thought into why it doesn't work instead of why I shouldn't be using it. I have used it before in 2.0 and it does work. I want to know if the newer .NET changed anything or I misused the option.
Direct Answer: it works in Visual Studio's web server , not in IIS.
The web application is hosted in a process that does not have a desktop, so you cant see any messageboxes.
#Tony, if you add System.Winform.dll to your rference, then you will be able to call message box.show at you development machine. But when you deploy it to some live server it will not work. So alternatively, you need to use javascript alerts. For this you can use this
private void ShowMessage(string message)
{
ScriptManager.RegisterClientScriptBlock(control, GetType(),"key","string.format("alert('{0}');",message),true);
}
Back in .Net 2.0 days, you could do this by including system.windows (I think) in your using statement.
Then, in the method, it would be system.windows.forms.Messagebox.show("foo");
I won't presume to tell you "yer doin it wrong"...
Just be aware that this will only show up on the server box, and could cause issues in a production environment.
The alert() is better, and console.log() is even better.
Related
Let's be clear, I don't really like WebForms. Which is why I do not wish to spend hours debugging a legacy code base that ran perfectly well on one server (IIS7) and a new one (IIS8).
I heard there is this new ClientIDMode, which makes forms and other controls change their IDs or not to something sensible, but I didn't touch it. It seems like the default value has changed (ie is not backwards compatible)?
I had a form in a master page that looked like <form id=SiteForm runat=server
This automatically changed its ID to aspnetForm in the rendered output.
Sure it was a bit weird, but I have a lot of code in this app that relies on it. I could simply change the ID in the server page to <form id=SiteForm runat=aspnetForm and that might fix it. But maybe there's some code in this old project that uses SiteForm on the server side, so I can search for that.
But there could be other controls lurking around which had their IDs changed too. So maybe there is something I can add to the web config to turn the behaviour back to what it was before? What was the default before?
UPDATE: Looks like when exporting and importing the app pools this site somehow got changed from .NET2 to .NET4, so perhaps I just need to set it back to .NET2?
I found that I had not ticked the box to install .NET 3.5 within IIS setup. This is why all my app pools reverted to .NET 4 automatically and why these weird changes happened. So I installed it in IIS, restarted, and set the app pool to .NET 2 (ie 3.5). This fixed it, cleanly, so I will call that the solution.
I have an ASP.NET web aplication using vs2008. It used to let me hit my break points but for some unknown reason in this site it won't let me hit them any more.
I have set everything to debug and re built about a million times and everything else but can't seem to hit that damn break point!!! Break points work for the site but not the class libraries I add in, but they used to!!
I can't see anything in the web config or the configurations to change anything. I've added the class library to a test solution, works fine.
Does anyone have any ideas?
Just to confirm, breakpoints work for the site but not for the class library. That means VS is attaching to the right instance. Put a break point right before the class library is invoked and see if it will drill in. If visual studio can't generate the metadata for debugging, it does a jump over. Confirm you also have the PDB file from the class library present.
Also, if you've recently updated the class library, be sure to stop Cassini and restart.
I've just started developing silverlight applications. I've created a webserivce in my asp.net project. Now, when I try to connect to it through my silverlight project I receive the following error:
"the opreation is not supported for a relative uri"
I am using the following url -->
http://192.168.1.2/MyWebsite/SubVersionedHistory.svc
I can find the class and its methods, but I receive this horrific error when I add it.
Thank you for your help and advice,
Vondiplo
I don't think you're alone in hitting this problem. I hit it today with VS2008SP1 + SL2 trying to create a Service Reference for an ADO.NET Data Service. First time I've hit the error.
Others have detailed similar experiences to reach this error:
http://silverlight.net/forums/t/87535.aspx
http://silverlight.net/forums/t/56629.aspx
It's not entirely clear at this point if the issue is with the IDE "Add Service Reference" dialog or something specific in the services causing this error. In my case, however, my code still worked despite the error message. I simply passed the URL to my service in the constructor of my DataService proxy client, like this:
var context = new DataServiceContext(new Uri("NorthwindDataService.svc", UriKind.Relative));
Summary point: Just because you hit this error in the IDE, your service reference may still work. Give it a try and let us know if you're seeing errors at run time.
Hope that helps.
[UPDATE] Based on some other advice I've found and tested, you can also try:
deleting your Service Reference
deleting your ServiceReferences.ClientConfig file
saving your solution
and then closing and reopening it in VS.
The simple act of closing and reopening your project has been shown to fix several problems with the Add Service wizard. Re-run the Add Service Ref wizard and you may have better luck. I personally tested this solution on a project today and can confirm it works. Hope that adds extra help to finding your solution.
You should be more specific about your problem. For example, are you having this problem when adding the reference or when you actually try to consume the service?
It sounds like you need to be using a full path, including the "http://" but that is just a shot in the dark based on the error message you provide.
[edit]If you are using the built in ASP.NET server instead of IIS then be sure you set a specific port number and use it in your path. For example, I have used http://localhost:4940/MyService.svc for testing[/edit]
Maybe this response can help you
You cannot use AbsolutePath, You need to use AbsoluteURL. Build your URL this way:
Uri url = new Uri(App.Current.Host.Source, "../settings.xml");client.DownloadStringAsync(url);
http://silverlight.net/forums/p/28912/95541.aspx
HTH
Braulio
Check the ServiceReferences.ClientConfig
if there are multiple endpoints there you will get this exception. one thing that can cause this is referencing a service using casini, later switiching to IIS express and rereferencing the service.
Hey I am coding using Visual Studio 2003. My program worked fine until I introduced a dll I made using CreateObject.
Code:
Set docs2 = server.CreateObject("DocGetter.Form1")
docs2.GetDocument oXMLDom,numID
It appears to be getting stuck at this code. I've already used regasm to register the dll.
What else could be wrong?
Add a reference to the dll in your project and instantiate the object like this:
Dim docs2 As New DocGetter.Form1()
If that doesn't make sense, then fix it so it does. There's no good reason to use CreateObject in .Net code. (Okay, that's hyperbole. But the principal is sound).
Can you clarify - is this a web app or a client (winform) app? Form1 sounds like a winform. ASP.NET runs at the server, so showing a form would be inappropriate - it would happen at the server, not the client. In short, don't do this!
I also can't see where "stored procedures" figures in this, so I've removed the tag.
What are you trying to do? Options for showing something more complex at the client include:
dhtml
flash
silverlight
clickonce [requires windows client]
ocx [not recommended]
I'd bet money that this function isn't defined with this name and/or parameters.
docs2.GetDocument oXMLDom,numID
But because of the way you're instantiating the object, the compiler has no way of knowing this... I think.
When an ASP.NET application errors out and generates the yellow-screen display, I'd like to create some kind of link from the error page which would jump directly to the correct line of code in Visual Studio.
I'm not sure how to approach this, or if there are any tools already in existence which accomplish it - but I'd love some feedback on where to start.
In the event that generating a new error page is necessary, is it possible to replace the standard yellow screen across an entire webserver, rather than having to configure the customized error output for each application?
You would probably need to embed an ActiveX control in the page for something like that to be possible.
The yellow screen of death is served by the default ASP.NET HTTPHandler.
In order to intercept it, you would need to add another HTTPHandler in front of it that intercepts all uncaught exceptions.
At that point, you could do whatever you want for your error layout.
Creating a way to directly jump to Visual Studio would be tricky. I could see it done in IE via a COM/ActiveX object.
The yellow screen of death is just a 500 error as far as the server is concerned, you can redirect to a custom screen using the error section of the web.config. To make a whole server change in the same manner you could probably override it at the iis level? Or perhaps even set the default behaviour in the machine.config file (not 100% sure about that one though)
The yellow screen of death is just a 500 error as far as the server is concerned, you can redirect to a custom screen using the error section of the web.config. To make a whole server change in the same manner you could probably override it at the iis level? Or perhaps even set the default behaviour in the machine.config file (not 100% sure about that one though)
If you let it bubble up all the way to IIS you will not have any way to access the Exception information. Its better to catch the Exception before the YSOD and serve your own.
This can be done at the application level.
Don't forget that you need the Program Debug Database (pdb) file to find the source code line number. An application in release mode won't have the same level of information as a debug release.
The easiest, laziest thing I could think of would be to have the process happen thusly:
The yellow screen is modified so the line is source code is clickable. When clicked it delivers a small text file with the source file name and line number.
A small program on the PC is tied to the extension of the small file the yellow screen let you download. The program uses visual studio's extensibility model to open the source file and goto that line. The program may need to know where your source code is.
A simple Google search
gives helpful pointers on how to manipulate VS with an external program such as this post on MSDN.
If you want to go snazzier, then there are certainly other methods, but I'd rather write out a quick and dirty program, and get it out of my way so I can be about my business.
Don't let the tools become projects...
-Adam