I have an app that works locally but there's a failure in Azure which I believe it could be due to the fact that I have a setting name that contains a $ character: NAmespace:ComposerAdapters:CompanyAdapter:$kind = SlackAdapter
I'm putting that by hand in the configuration blade in Azure. And that adapter is not being loaded when deployed in Azure.
I couldn't find anywhere that I can't use $ in the name but it could be the problem.
Related
I'm using OCP ver 3.9 and using jenkins pipeline to deploy to OpenShift. Usually, when I expose a route via this code:
def app = openshift.newApp("${IMAGE}:${imageStreamTag}", "--name=${appName}${appMajorVersion}")
app.narrow("svc").expose()
The exposed route will have the convention http://appName-projectName-clusterName/ (e.g. http://service1-myopenshiftproject-openshift.development.company.com.au/)
What I need is for my applications to have a common hostname (I don't want to have the application name and project name in the main/parent url --the one after the http://... ) , something like
http://openshift.development.company.com.au
I read about the hostname parameter of the oc create route command and I tried it in the Jenkins pipeline. I'm also following this link https://www.redhat.com/en/blog/how-deploy-multiple-versions-api-using-paths-openshift though for a slightly different purpose (exposing multiple api version using paths)
def app = openshift.newApp("${IMAGE}:${imageStreamTag}", "--name=${appName}${appMajorVersion}")
app.narrow("svc").expose("--path=/api/${appName}/v${appMajorVersion}", "--hostname=openshift.development.company.com.au")
The service got exposed according to the OpenShift web console, but when I try clicking the url found in the Overview tab of the OpenShift web console which lists down all the applications, this is what I got:
This site can’t be reached openshift.development.company.com.au’s server IP address could not be found.
How can this be done? Any leads are appreciated.
I have an Azure service containing a web role. Both configured to run on IIS Server locally. I would like to build/deploy and start the web role in a specific URL in Visual Studio. It always ends up in addresses using 127.0.0.1 even I specify what project URL is in the project configuration. Is there any way to change this something like dev.xxx.com?
You're running through the local emulator I assume. As such, the URL project settings won't apply. Just like if you deploy it to the cloud, you'll need some type of DNS forwarder or alias.
I've created a Silverlight application that uses a service. The service is defined in the web project in that solution. The silverlight application references it and uses it.
Everything works locally on my dev machine when I run the application in Visual Studio.
I note that the url im given from VS is: http://localhost:50453/Default.htm
But when I deploy this (by filesystem copy deploy option) the web page starts and it looks okey except that it seems to have a problem using the service.
In the Silverlight application, if I look at the reference settings the url to the service is: http://localhost:50453/SilverlightService.svc and thats probably whats wrong, as the server that Im deploying to does not have a clue whats on port 50453.
So Im trying to change this port to 80 on my dev machine but Im out of luck. My web project does not have any property where I can change the port. Opened URL and URL is locked at http://localhost:50453 :-/
How can I change the my dev environment to match the production environment with port 80?
For sure you can change the web project's URL in project properties, but this is not a good solution because you'll get the same problems when accessing the SL application from a remote computer.
You need to set the service URL programmatically, like above:
ServiceReference1.Service1Client svc = new ServiceReference1.Service1Client();
Uri serviceUri = new Uri(System.Windows.Browser.HtmlPage.Document.DocumentUri, "Service1.svc");
svc.Endpoint.Address = new System.ServiceModel.EndpointAddress(serviceUri);
This solution uses the same URL that you are using to access the Silverlight Application.
I am working with Windows Azure and am just using the Blob Storage. I have setup my Blob Storage to run in its own Solution file with a dummy web role. I run it first on my development machine so the Azure Services start. I have configured the service to use the development shared key and account name.
I am running into an issue when I point my web application (in another solution) to the local Blob Storage service. I can upload a file to the Blob Storage and I can see the records in my local database. Therefore, I have entered the correct settings in the web.config. However, I cannot access the file via a simple Get request. I have verified that the container is public.
The URI I am using is:
http://127.0.0.1:10000/{container-name}/{filename}.{extension}
My code works when I use my production Azure Services, so is there something different about the Development Environment that I am missing? Does the local environment allow REST access?
UPDATE: I recently found this MSDN Article that describes the differences between production and development Storage URIs. I also documented my environment here on my blog.
The uri looks to be slightly incorrect, the format for the development storage uri is:
http://<local-machine-address>:<port>/<account-name>/<resource-path>
Given that the account name is always devstoreaccount1 your uri should be:
http://127.0.0.1:10000/devstoreaccount1/{container-name}/{filename}.{extension}
What kind of response or error code are you getting?
If you are using IE- you can install Fiddler or use the built in developer tools in IE8 to help debug a communication problem.
Sure- the development fabric works in REST!
I'm testing a ClickOnce application deployment. I have setup a virtual directory on my machine (running IIS). I have specified http://localhost/SampleApplication as the Installation Folder URL in the Publish tab of Visual Studio. However, when I publish the application I get the following error:
Warning: Files could not be downloaded
from http://chrish/SampleApplication/.
The remote server returned an error:
(407) Proxy Authentication Required.
Publish success.
Warning: Unable to
view published application at
http://chrish/SampleApplication/publish.htm.
http://chrish/SampleApplication/publish.htm
Notice how it has changed my url from Localhost to my login name. Why? This wasn't happening a week ago.
ClickOnce installation involves verifying that the server name matches the expected name. Thus localhost always gets translated under the covers to the computer name [not the username as you suggest in your question] (one of many confusing things ClickOnce does - one side effect of this is that if you want to set up 3 download servers, you need to do 3 separate publishes and/or script the publish like this) or like this. So this is not a surprise - it's always doing that under the covers.
The 407 error relates to proxy auth. This implies downloading is being diverted via a proxy such as Microsoft ISA Server. Have a look in your IE Internet Options Connections Proxy Settings and make sure its bypassing for local addresses [such as chrish].
The reason it's reporting success is that the upload likely uses an alternate mechanism than the verification does and isn't being routed via / blocked by the proxy. (The underlying problem is that the .NET framework does not by default pass proxy credentials and you'd need to either apply a config entry for devenv or whatever does the publish or have the build process call a test step with extra code that does send the proxy credentials](http://blogs.msdn.com/jpsanders/archive/2009/03/24/httpwebrequest-webexcepton-the-remote-server-returned-an-error-407-proxy-authentication-required.aspx). See also How should I set the default proxy to use default credentials?)
ClickOnce doesn't like "localhost", but you can work around that.
If you set the Publishing Folder Location to:
C:\inetpub\wwwroot\SampleApplication\
and the Installation Folder URL to:
http://chrish/SampleApplication/
(where "chrish" is the network name of your computer) then you can publish locally.