I am currently trying to create multiple Applications within a single IIS-Website automatically.
Each application represents a Feature-Branch of a developer/feature.
The problem is, that the legacy application is not really made for running in a path that is not on the root. So the path the application thinks (and must think) it is running in, must be '/'.
It would come with re-structuring and re-testing pretty much everything related to urls, to change this. So for now, its not an option.
What i currently have:
[Features (Site)]
- [Feature_A (App)]
- [Feature_B (App)]
This results in Feature A being available under http://server/Feature_A and Feature B respectively.
Now when the Request reaches the application, the application must think that the url in which it was called is "http://server/" (or the Path being "/").
Chosing the correct app was achieved with the IIS URL-Rewrite module, and works quite well.
I use a cookie to decide which app to call, and the original '/' is rewritten to '/Feature_A/'
But now, when trying to eliminate the "/Feature_A" part of the Path within the app seems to be quite impossible.
Application.Context.RewritePath(newPath); // throws exeption -> different application
didnt really work out, because the new Path '/' points to a different application, and RewritePath doesnt like that.
Is there any way within the app or even in IIS to make the app think it is running on the root path?
Thank you in advance.
Related
I'm trying to create users in Google directory using the Google Directory APIs, specifically Google.Apis.Admin.Directory.directory_v1. If I add a user with an alias, it will fail with an error of "If-Match - Error with format of alias" but if I create the user first and then add the alias afterwards, it succeeds.
The really strange thing is that this used to work. Starting somewhere around November 2021, code that I've had working for a few years stopped working.
I would recommend keeping user and alias creation as two separate API calls. That way if one fails you know whether it's the user create and primary address that's the problem or the alias address which is a problem.
Having said that, can you show your full API call including the POST url and body?
big shot in the dark, seems they increased their sensitivity and added more limiting on their servers "Cloud IoT Core automatically limits projects that generate excessive load"
Especially if this script used to work fine, try using a backoff script.
https://cloud.google.com/iot/docs/how-tos/exponential-backoff
if not, I tried ^^
I am using Microsoft's App Center with a .NET Core 3 WPF app. I do not want to store my app center key in the source code directly, as my software is open source. I'm using Visual Studio, and I've googled around on ways to not store my API key in the source code directly. I know you should not store them there, but when it comes to build time, I need to have the API key accessible as a string to the code so it can pass it off to a method call.
I am not extremely worried about someone running my app through a disassembler, but I would like to thwart the casual people who might want to poke around more than they should. In Visual Studio/c#, I can't seem to find any way to do something like this. Like a #ReadFromFile(filepath) directive or something that could read the contents of a file and substitute it into the document at compile time.
Does anyone know of a way to do something like this? I have seen many answers about "how you should just never do it", but I don't really have the resources to do what a lot of them do. I just have a fairly simple application that's open source and uses an API key.
I think there are 3 possible solutions:
Put the key in a file that your application will read at startup and exclude this file from version control.
a) Put your key in the Environment Variables. This is the way you would do it for a cloud application.
(but because you need it for a desktop application every program on your PC can read them)
b) If you are working only on windows put it in the windows registry. (other programs can reed this too)
Call your Program with the key as a parameter. You can create a batch/powershell (on windows) or bash (on linux) script or create a desktop shortcut so that you don't have to start you application over the terminal all the time.
(Additionaly you could also encrypt the key and ask the user for a password on startup. So even if other applications can read your key they have only the encrypted data.)
I have a Windows 8 app that downloads the online assets, unzips them into the LocalState folder, and accesses that content when the user is offline. I use a custom IUriStreamResolver to provide the content. The local URL might look like this:
ms-local-stream://package-name_application-key/.../.../
The part I'm after is the application-key. While the package-name is in the Package.appmanifest, the application-key is not. I've also verified the package-key is not part of the LocalState path. I'm wanting to use WebView.BuildLocalStreamUri and it requires the contentIdentifier, this is documented as the concatenation of the package-name and application-key.
I've done quite a bit of digging through the API's via the Object Browser, and of course I've pretty much exhausted Google and DuckDuckGo (love that search engine BTW), and they've not provided any fruit.
Does anybody know how I can get at that key the app generates and uses for this?
Apparently it doesn't actually matter what the value is. It has no bearing on the URL that is formed. I wanted to answer this for the next person trying to use this method. It just cannot be null or an empty string.
I'm messing around with the cheapest .NET Arvixe server for learning purposes and try to install an application (Umbraco in this case) in a particular way.
Arvixe count's subdomains as websites, which means I'm currently limited to 6 of them. With some clever URL Rewrite trickery, I managed to setup the following structure.
FTP-folder:
> mydomain.com
>> wwwroot
>> subdomains
>>> subdomain1
>>> subdomain2
>>> etc.
wwwroot is the main website, under which I added Virtual Directories for each subdomain. So if in the browser you would go to http://www.mydomain.com/subdomain1, you'll end up seeing whatever app is installed under subdomains/subdomain1.
After applying some URL Rewrite, I can go to http://subdomain1.mydomain.com, and it will show me the same content as if I would go to http://www.mydomain.com/subdomain1
Now this is where the problem I'm experiencing begins.
Whenever in code I would do a relative path (eg. ~/Blog/Test/123.aspx), it will resolve to http://subdomain1.mydomain.com/subdomain1/Blog/Test/123.aspx. This all still works, as the everything is still under a single website, I just don't want the /subdomain1/ part in the URL. If I manually remove the /subdomain1/ part, the page also render fine due to my rewrite rules.
After some searching I found out that internally, whenever code has to resolve a ~/-url, it will use HttpRuntime.AppDomainAppVirtualPath for that.
How can I trick ASP.NET into thinking it's hosting under the Virtual App Path of '/' rather than '/subdomain1/'?
I have tried a few things which do not work (or I just did it wrong):
- Thread.GetDomain().SetData(".appVPath", "/");
- Make a VirtualPathProvider
In all cases, it will throw exceptions.
Is hosting under it's own website really the only solution (which means I have to upgrade the account)?
I tried all kinds of hacks by means of Reflection, so it's certainly not possible by normal means. In the end I got as far as confusing IIS, as the ApplicationRoot wasn't overwritten on all locations. So I gave up, it's not possible.
I am trying to make a simple application which will be used to point a web browser control to some of our web applications at my work. I would like to have only one exe file but also have an admin window to change some of the settings and have them persist when the application is closed. Is that possible? I have looked at the application settings resources part but as I understand that makes a file that loads the settings.
I don't want to have to parse a file or have anything but ONE file so please don't suggest doing that if it is possible.
Just use application settings - that will create a single file, you won't have to do any parsing, it'll all be fine.
It'll be separate to the exe file, but unless you meant that "ONE file" to include the executable and rewrite that on the fly, it should fit your description easily.
For example, let's build a console app that just remembers how many times it's been launched:
Create a new console application project
Go to the properties page, and click into the Settings tab.
Click on the link to create a settings file
Type in the table to create a setting called "LaunchCount" of type int. Make it either user scope or application scope, depending on whether you want it to be persisted per user or system-wide.
Hit Ctrl-S to save.
In the Main method in Program.cs, write this code:
Settings settings = Settings.Default;
settings.LaunchCount++;
Console.WriteLine("Launch count: {0}", settings.LaunchCount);
settings.Save();
Add the appropriate using directive for Settings (put the cursor in Settings and hit Ctrl-.)
Run the app several times, and observe the number increasing.
You can't have persisted settings without having a separate file...safely. You must either have a separate file, which is the standard and suggested approach approach, like the one created with Application settings, or you must use something like the registry to save settings.
Keep in mind, though, that using the registry is highly discouraged due to security reasons. Plus most companies don't allow access to registries anyway which means that anyone without this access could not use the settings feature.
There are several ways to do this. You can use a command-line argument to do that. Launch the app from the shell and put in your command line argument and change how it launches.
A UNIX-y approach is to look at the name of the exe and change behavior based on that. If I recall correctly, rsh and rlogin are the same executable - they just look at argv[0] to decide how to run. In windows, this is straight forward - look at System.Environment.GetCommandLineArgs - if there is a non-empty string in the 0th element of that, it will be your executable name.
For persisting settings, see Jon Skeet's answer.
I have to say that this is generally a bad idea, but I've done this before a long time ago in VB6. I created a Resource within the exe and then (somehow) directly manipulated it.
The problem is, is that this is usually not possible within the .NET framework due to it being memory resident. These guys tryed it out in .net and they ended up creating an program in IL to do the heavy lifting... Modify Emdeded String in C# compiled exe
Go with a settings file as Jon suggested!