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 ^^
Related
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.
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.
In my win forms C# app, I want to be able to add spell check functionality. But, I want to do it my own way, and NOT use any other components. All I need is just an online service where I can send a request or something and it tells me whether or not the word i sent was spelled correctly.
Preferred but not required: The ability for that online service to also send back suggestions.
Personally, I wonder why you want only online access...what if you lose connection? Also, most online accesses come with restrictions.. which you might hit sooner than you think during debugging.
If you were to use WPF, I'd suggest using the SpellCheck Class.
Since you specified Windows.Forms, you might try the NetSpell library for offline access. You can also try and use Microsoft Word's spellchecker, but you might not have it installed on the machine (or use Linux & Mono)
If you persist on using online access, you can use Yahoo, as Giovanni Galbo says. It's been done in C# before.
A quick google search turned up this:
Search Web Services: Spelling Suggestion
This is not c#/.NET specific. Its a simple REST service provided by Yahoo!. It looks like they do limit you to 5,000 queries per day for free and I'm not sure if Yahoo! lets you upgrade to a pay service.
We have a pair of applications. One is written in C# and uses something like:
string s = "alpha\r\nbeta\r\ngamma\r\ndelta";
// Actually there's wrapper code here to make sure this works.
System.Windows.Forms.Clipboard.SetDataObject(s, true);
To put a list of items onto the clipboard. Another application (in WinBatch) then picks up the list using a ClipGet() function. (We use the clipboard functions to give people the option of editing the list in notepad or something, without having to actually cut-and-paste every time.)
In this particular environment, we have many users on one system via Citrix. Many using these pairs of programs.
Just one user is having the problem where the line delimiters in the text are getting switched from CRLF to LF somewhere between the SetDataObject() and the CLipGet(). I could explain this in a mixed Unix/Windows environment, but there is no Unix here. No unix-y utilities anywhere near this system either. Other users on the same server, no problems at all. It's like something in Windows/Citrix is being "helpful" when we really don't want it, but just for this one guy.
Ideas?
Have you tried clearing their profile on Citrix? That seems to be the solution to many many user specific Citrix problems.
Does Environment.NewLine behave differently on Citrix environments? If so, it may give you a good option that works for all users instead of \r\n.