I'm trying to import a web application into IIS7 using Web Deploy. I packaged it into a ZIP file using Visual Studio's "Publish Web" functionality, and when I select the zip I get to my "Application Package Information" screen.
One of the settings it asks me for is "Application Path". If I leave that empty (so it basically just says "My Website/"), and try to continue, IIS gives me the message:
This application will be installed into "My Website". Most applications are usually installed into a folder beneath the root, such as "My Website/Blog". Are you sure?
I can't understand why it gives this warning. I'm tempted just to say "OK" to this dialog, but I wanted to check first - is there something obvious I'm doing wrong? Surely if I want my web application to be the entire web site, I want to install it to the root or otherwise users will always have to access http://host/MyAppDirectory/ instead of just http://host/ - why would I want to have the unnecessary suffix MyAppDirectory/? Is it better practice to install the application to MyAppDirectory and somehow map that directory to the website root, or is it OK just to install the application to the website root despite the warning?
In addition, assuming it is OK to install the application to the website root despite the warning, is there a way to completely remove the "Application Path" setting (and the related warning) from the "Application Package Information" screen, and always assume that the app should be installed to the website root?
If it's your primary web app, then it's fine to ignore this message. It seems that a lot of people like to run completely separate applications for their site so there will be http://domain.tld/forum/, http://domain.tld/blog/, http://domain.tld/something_else/, and also http://domain.tld/ and each will be a separate web app.
I don't know how to disable this warning, but I'm rather certain you know what you're doing to the point you can ignore it.
Personally, if I'm going to run web apps under the same site, say /blog, /forum, and / I'll have a file system layout like the following:
/var/www/blog || C:\Sites\Blog
/var/www/forum || C:\Sites\Forum
/var/www/site || C:\Sites\Site
In that case, I'd get the same message for publishing to each and every one.
You seem to know what you want to achieve as your end goal so I'm inclined to suggest you ignore that message. Hope that helps.
Related
Previously, I could write an addon for personal usage packed as something.xpi and I clicked on it to install it.
After a while, mozilla introduced xpinstall.signatures.required which you could still get around it.
However, it did not stop stabbing developers who are interested to have a personal addon isolated from the world. Today, only web extensions are working and my XUL based addon is thrown away. The tutorials only talk about temporary installation of a web extension while I want my one runs on firefox forever.
Beside whether I can use web extension to write into files or create a GUI in an independent page, I have a bigger challenge:
How can I install a local web extension permanently without creating a Mozilla account for personal usage?
Navigate to the folder where your extension is located. You can build it in the usual way using web-ext:
web-ext build
You can install this ZIP file permanently in Firefox by going to about:addons and dragging this file into the tab.
In order for this to work, you need to set xpinstall.signatures.required to false in about:config (works only for Nightly and maybe Developer Edition).
Apart from setting xpinstall.signatures.required to false, you need to add this to your manifest.json:
"browser_specific_settings": {
"gecko": {
"id": "some-name#example.org"
}
}
Found on https://www.reddit.com/r/firefox/comments/blqffs/how_to_permanently_add_temporary_addon/exh2u3o/, thanks to "alexherbo2".
You need a "blueish" Firefox -- Developer Edition (effectively beta) or Nightly (unstable, updated every night).
You can get them from https://mozilla.org/firefox/channel/desktop/.
Then xpinstall.signatures.required will work again.
(As for permissions--you can create a GUI in a tab or a popup, but I don't think you can do it in a separate window (unless you do a webpage-style popup window). You won't be able to write to arbitrary files anywhere on the system--which is a good thing! You can write to the Downloads folder, and read/write some sort of internal storage, but that may not expose the actual files involved. For more information see https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_files.)
What you should be looking for is having your extension signed by Mozilla as Unlisted.
See Mixing Listed and Unlisted Add-ons on addons.mozilla.org blog post for an overview.
That way, AMO does not host nor (normally) review your extension; it simply runs some basic automated checks and immediately signs your extension so that it can be privately distributed as an XPI.
For those interested in developing/running an extension from a local directory without having to package or load it manually via "Load Temporary Addon..." from about:debuggin#/runtime/this-firefox please go to this github repository.
From the README.md:
The procedure involves a few steps, but it needs to be done only once.
First you need to enable AutoConfig aka userchrome.js by copying the file config-prefs.js to [Your Firefox install directory]/defaults/pref
Note: For best security, on Windows it is best to leave your Firefox install in "c:\Program Files" so that your config-prefs.js and userChrome.js can only be modified when you are in root/admin mode.
Then you need to edit the file userChrome.js and modify the function installUnpackedExtensions() to reflect the locations of your own addons.
The modified userChrome.js then must be copied to your Firefox installation directory. For example on Windows this is usually "c:\Program Files (x86)\Mozilla Firefox" for the 32-bit version of Firefox. You can rename the file, but remember to modify the corresponding line pref("general.config.filename", "userChrome.js") in defaults/pref/config-prefs.js
Now your addons from your local directories will be loaded automaticaly whenever Firefox starts. After editing your code remember to reload it from about:debuggin. You can also get there via the menu by selecting "More Tools", then "Remote Debugging", and click on "This Firefox" on the left side (but the quickiest way is to bookmark it and then add a bookmark keyword such as "dbg" for quick access.)
Please note that this is an automated install of the extension every time Firefox starts, so it is not quite the same as a "permenent install". That is, this procedure has exactly the same effect as clicking on "Load Temporary Addon..." from the about:debuggin page, just that the process is now automated via userChrome.js. This means that if you have code that does something after the installation of the extension such as browser.runtime.onInstalled.addListener(details => { if (details.reason == "install") { ...do something after install... }); then this code will be called every time Firefox is launched.
You can try setting the preference extensions.legacy.enabled (this will only work in Nightly or Dev Edition).
I'm creating a cordova app for Windows.
Now when I build this normally (with my own identity of which I have no clue where he gets it from) everything works fine and my app launches with success.
Although when I then associate my app with the Store, and have my actual app name + package name etc filled in for me, I get a blank screen when trying to run my app.
The head and body tags stay empty and no error is thrown in my JavaScript console.
Any idea of why this happens? The problem definitely is that I associate my app with the Store and then something happens which makes my app crash or fail to start.
But why does it do this? And how can I resolve it?
(currently building with VS2017)
edit
Alright, so I figured out that because the package name changed, I had to edit that as well in the manifest. Now My main root component is loaded, but it isn't setting the app root to any page, just a blank screen. (with a menu that can open on swipe).
Alright, so my Microsoft assigned package name was different than my own. This caused the app to look for my own package name instead of the Microsoft one I associated with.
The solution was quite simple, just set your widget-id in your config.xml to the Microsoft assigned package name and rebuild your solution.
(I was using Ionic framework so re-execute ionic build windows --release --prod --arch="arm")
I am working on a website which authenticates with Facebook, so that the user can sign in through his/her Facebook profile. I've seen similar questions like this one, but none that covers exactly my issue.
To test this Facebook authentication locally, I figured that some hacks were needed. You see, Facebook only allows redirects to certain domains after the authentication process. For these domains, localhost is not an option.
So I decided to do some research. I ended up changing my hosts file to point the domain local.fablelane.com to 127.0.0.1. However, now it complains when I try to change the virtual directory in Visual Studio 2012.
First, I see this dialog after changing it.
I then click Yes and end up with this dialog here.
What do you suggest I try? How can I change my virtual directory? It is important that I find a way to do this either programmatically, through changing a file somewhere, or through the commandline. The reason for this is that I intend to make an automatic setup program that does this for me in the future.
You will need to uncheck Use IIS Express and also add your new name local.fablelane.com as a binding to IIS, so that when VS tries to open the site URL, the host-header matches the site.
Also, is there any reason you need a specific port, rather than the default? It should be fine with 80.
You haven't said which version of IIS you're using, but on 8, open IIS Admin, expand your machine-name, expand Sites, right-click on local.fablelane.com (or however you've named it), and select Edit bindings and add local.fablelane.com.
Try uncheck the option "Use IIS Express".
Check if your website port number in IIS has been changed.If its changed edit bindings and change port number to 80
In addition to the above, click on the override application root URL and paste the host name address which you have given in the Project Url.
It worked for me.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html
Hoping someone can provide an answer with this, although it's not 100% programming related. All of a sudden my IIS6 install on Server 2003 will give me a "404 Not Found" error when I try to load any file ending in .asp.
I can see the file there if I turn on directory browsing, but clicking on it immediately gives me a 404. Regular HTML pages load just fine, it's only the ASP files that it cannot find, although they're right in the directory alongside the HTML file.
I'm probably forgetting something stupid - can someone remind me what I need to do in order to get it to load properly?
In the Web Service Extensions area, make sure Active Server Pages is enabled
We ran into this issue of late. Besides the Web service extensions where one enables asp, there is another place in each site that needs to be checked.
Virtual directory:
In IIS 6.0, open the properties of the virtual directory. Navigate to virtual directory tab - at the bottom, click on configuration - make sure that the .asp extension is in that list. If it's not, you can find the dll somewhere like this path: C:\WINDOWS\system32\inetsrv\asp.dll. Also, the verbs will need to be added on this same window. The main choices are GET, HEAD, POST (and maybe TRACE if need be).
Web site
In IIS 6.0, open the properties of the site. Navigate to Home DIrectory tab - at the bottom, click on configuration - make sure that the .asp extension is in that list. If it's not, you can find the dll somewhere like this path: C:\WINDOWS\system32\inetsrv\asp.dll. Also, the verbs will need to be added on this same window. The main choices are GET, HEAD, POST (and maybe TRACE if need be).
I hope that helps - I didn't find this mentioned after a fairly extensive search.
Duh - I knew it was something stupid that I just overlooked (shows how often I use Classic ASP). Thanks a bunch.