AjaxControlToolkit | NET AJAX Control Toolkit is a classic set | Model View Controller library

Ok, after changing browsers to Chrome I was able to see more of the error. It was for file type not allowed. Strange, but I defined the filetypes in my config file and it is working now.

First, you don't want to "place" anything at all in the bin folder. For one, if you do a from the menu build->clean solution then all of the bin files and folders are removed from bin. So, your project needs to work, compile and run without anything in the bin folder WHEN you do a compile, or MORE important when you do a rebuild, and super more important of course is when you create a deploy, then what's in the bin folder is re-created anyway. So any idea of placing .dll's in the bin folder is not only a bad idea, but it fruitless and should not be done EVER anyway.

Script manager on the master page. This is good and recommend so you don't have to mess around doing this page by page.

However, you should tell the script manager what scripts to combine and load.(but different issue - since that should not effect the ajax tool kit.

Where you have to watch is the web.config file. You need to include the ajax tool kit assemblies you are using.

Say like this:

And then in the pages section, you should have/see this:

You can't add a server side button or inject a server side button into the page DOM.

When you drag a asp.net button onto the form, BOTH the "mypage.cs" and mypage.desinger.cs ARE updated. The wire up of the button occurs at design time, and you would have to modify mypage.desinger.cs ALSO and ADD a button event stub.

So you can't do this.

A compromise would be to also add some js and have that HTML button execute a .click() method of a hidden asp.net button you drop into that page (that would give you the post back, and the running behind of a separate button event code stub.

This event resolution occurs at compile time - not at page render time. You have to drop that button onto the page.

I suppose you could adopt a standard that you always place right below that "div" on the page the button (hidden with style=none. And then as noted, have your injected code along with some js execute a click on the hidden button. Or just have the js button code execute a __doPostback("some value") and pick this up in the page on-load event, and then call the routine (function) from on-page load event.

I think better would be to use a jQuery.UI dialog, as that dialog CAN say load + use another different web page into a “div” on the existing page. So you layout, make, and create the nice looking popup form as a separate web page. jQuery is able to remove the “form” and additonal tags out of that page load, and then inject it into the existing page. (that code would be rather hard to re-produce). so jQuery.UI is able to pop up that separate page. however, the buttons on that loaded page (into that div) of course can't really run any code behind in the current page. However, the buttons CAN run local js in the current page. Thus the actions of this injected page would be local to each page. But the popup would not be directly calling a code behind stub.

Now, to adopt jQuery.UI, then you also have to of course adopt jQuery. So that is two extra libraries you need. (but, jQuery you likely already have).

However, I suppose the whole point of using the ajax toolkit is to avoid jQuery.ui in the first place. To be fair, before jQuery.ui came along, that tool kit was REALLY impressive, and gave asp.net folks a REAL leg up on the competition. (and it tends to be MUCH less wiring up then say using jQuery.UI

So the AjaxToolkit in its heyday was impressive. Now, it of course showing its age, but I still use the kit, and this is especially the case for the AjaxFileUploader. And yes I do use the popups – even to this day. However, I find now that jQuery.UI dialogs are more flexible, and would be better in this case (because you want a on-the fly setup).

Also, having code behind buttons in even the jQuery.UI dialog, or in this case the ajax popup? Well, only the action button can run code behind. The cancel button of course will just dismiss the dialog. However, any button in the dialog that WILL run code behind? Well, that's ok, since you have a page post back, and it actually the page postback that BLOWS out the dialog anyway.

Solved. Google Api works with IIS > 7 and stucks with IIS 7.

Simply upgrading the operating system solve the problem

Delete .vs folder if it exists. Go to Properties. In Web tab click Create Virtual Directory button

Well, you in ONE local routine create a table, add a row. And then the routine finishes and all the values, variables now go out of scope. Then that routine will be called again if a 2nd file is up-loaded, and you re-create the table. The variables in that routine (and in fact ANY routine - heck even if this was not asp.net go out of scope when the routine finishes.

At least with a desktop application you could declare the table at the form level (not sub routine level) and then you could add a new row to that temp table variable. But, with asp.net, then your web page is "state less". That means all variables ONLY have their state when code runs. The instant that code is finished, then all state in the code behind is lost.

But I am somewhat perplexed that you would think the data table would persist for each call? Perhaps you only want the var dtUpload to exist in the lifetime of each separate time that routine is called? But, then again you do nothing with the table????

So, for each file up-loaded? That routine gets called. So, lets assume 5 files are to be up-loaded.

Taking a really wild guess? I would assume we want that table/array to build up over time.

So, we need to ensure that the dtUpload table can "live" beyond a single page cycle and round trip. So, lets save/place/put/park the dtUpload table that can live "beyond" that one routine.

It really depends on what you want to do with that list after all is said and done?

Since the table is small? Then you could certainly in the forms on-load event create that table with no rows and shove it into say the Session(). Then as each file up-loads you could shove the file name into that array.

So, your code could work like this:

In on-load event only FIRST time, create the dtUpload table. And then shove/save it into the session().

So, our on-load would look like this:

Visual Studio Crashes When Adding a DataSet to a Report, Could not load file or assembly

For the issue, it is more related to your old project. Since the structure and the function from the new VS2019 asp net web project is quite different from the old one from the previous version, so when you migrate your project into VS2019, it might have some issues from time to time.

Or you could try the following suggestions:

1) first, try to add the related dll into the system global assembly caches.

Run CMD as Administrator and then input these:

Aha - found it!

Solution

The ASPX/HTML referred to http://ajax.googleapis.com. Changing the references to https made ModalPopupExtender.Show() work correctly for me.

Explanation/Diagnosis (if you can clarify further, please comment)

When I checked the html served to my browser, I noticed it defined a javascript function called fn(). The definition for fn() didn't appear in the html served to the server's browser. After the https change, fn() no longer appears in the html I receive. The other page, where ModalPopupExtender worked, didn't have any reference to googleapis.com.

I assume that using http instead of https caused ajax.googleapis.com to provide fn() and that fn() in some way interfered with the normal operation of my ModalPopupExtender.

Here's the fn() definition: (function {var fn = function() {Sys.Extended.UI.ModalPopupBehavior.invokeViaServer('ctl00_cphContent_ModalPopupExtenderConfirm', true); Sys.Application.remove_load(fn);};Sys.Application.add_load(fn);})();

Note: the http also included another javascript function related to the ModalPopupExtender. But there was a similar one on the working page, and in the working version served to the server's browser, and in my fixed version. So, I assume that function is correct.

Use a update panel and wrap your controls inside it. Then add the button controlID as a trigger (be sure its a PostBackTrigger) to the update panel. To test be sure to put a break point on the uploadFile_Click event so you can step through and see the values..