I'm trying to use the TeamCity REST API to update settings against a build configuration. Specifically, the checkoutDirectory that in the UI is in the "Version Control Settings->Additional Options->Checkout directory" textbox...
The documentation talks about updating the "parameters", but not the settings.
If I do a GET on /app/rest/buildTypes/<id>, the results include both settings and parameters...
I've tried various combinations of PUT request to try to update this, but having no luck.
Interestingly, if I do a GET on /app/rest/buildTypes/<id>/parameters, I get this...
Which includes the ID in the URL.
But if I do /app/rest/buildTypes/<id>/settings, I get this...
Which doesn't include the ID. Not sure if that's a bug - or I've completely misunderstood the scope of these settings, and they're global, not per build config - but that's certainly not what I'm seeing in the UI.
Any ideas how to use the REST API to update these settings?
I have a customized Account "Main" Form in CRM.
I added a new tab, a new section, and new fields inside it.
I published all customizations before-hand, then export, then import into my test environment. I publish all in the test environment.
The Unmanaged Solution contains this form and its new fields; When I review the Form XML in the exported zip's customizations.xml file, it indeed has the new tab label, new section label, I can see the fields in the XML.
PROBLEM: But after importing and publishing into the test environment... the changes don't show up!
What I see in its place is the way that section looked BEFORE (not sure how long ago last time it was changed). It's simply not getting my latest changes.
How can an Unmanaged solution import have these issues? What else is there to check/consider? I don't think Solution Layers would cause this since it's Unmanaged, nothing stood out there anyway.
Please follow this check list, also note* with Dynamics it needs more env/info including your environment to trouble shoot, since it could be something in tandem with your env.
1. Usual Suspects in an UnManaged Solution
With yours being an UNMANAGED solution, I strongly suspect its a security permissions issue not setup/enabled in the Target environment, check your logs, you may see something like this
Try these Solution Importing steps
Import your main solution (note* without field security profiles).
Now, Publish all your customizations (note* you can enable/import the field security after this step)
Lastly, Import the second solution which would contain your field security profiles
2. Troubleshooting Checklist
To resolve/hunt down the issue, try these checklist steps
Check IIS: if you reset/restart IIS, (after define and publish your field)
Clear you client side cache: run it by
pressing Ctrl+F5
Clear you server side cache:
https://learn.microsoft.com/en-us/powerapps/maker/portals/admin/clear-server-side-cache
Are using the entity form:
Do you have the correct: entity permissions Notes & Sub Grid
https://learn.microsoft.com/en-us/powerapps/maker/portals/configure-notes
Did you add the metadata
Lastly are you using activities
So it appears with the advent of ASP.NET Core 2.1, Kestrel now automatically creates an HTTPS endpoint along side the HTTP one, and default project templates are setup to redirect from HTTP to HTTPS (which is easy enough to undo).
However my question is... how can I disable HTTPS entirely for my project. I've read through the docs and played with a variety of config settings for HTTPS but nothing I do seems to allow me to turn it off and just run an HTTP project.
Am I crazy or just missing something. I would expect this to be super easy to do.
In the Startup.cs, remove the middleware
app.UseHttpsRedirection();
If you are using Visual Studio 2017, then you can do the following:
Go to your project properties. (Right-click > Properties)
Click on the Debug tab.
Under Web Server Settings, deselect Enable SSL.
Save, build, and try again.
This will update the iisExpress settings in the launchSettings.json file.
In the file Properties/launchSettings.json of your project, look of the key applicationUrl. You will find something like:
...
"applicationUrl": "https://localhost:5001;http://localhost:5000",
...
Remove the https endpoint and it's done.
Edit
As noted by #Xorcist the file launchSettings.json is not published. So, the solution above will only work in a development environment. To disable https and, in general, to configure the urls you want to listen to, both in production and in development, you can also do one of the following:
Use --urls parameters of dotnet run, will have the same effect as the applicationUrl in launchSettings.json. For instance: dotnet run --urls=http://0.0.0.0:5000,https://0.0.0.0:5001. Again, remove the one you don't want to use.
The same can be achieved with the ASPNETCORE_URLS enviroment variable.
As mentioned in the answer by #Konstantin to this question, in ASP Net Core 2.1 you can also configure Kestrel endpoints in the appsettings.json (it seems this cannot be done in 2.0).
Finally, the same can also be achieved with the useUrls extension method WebHost.CreateDefaultBuilder(args).UseUrls("http://0.0.0.0:5000"). I prefer the other solution because this ones hardcodes you're application endpoints, and can't be changed without recompiling the application.
All the possible options are explained in detail in the Microsoft Docs on this.
Update (09 Dec 2020): these options are still valid for Net Core 3.1, as per Microsoft Docs, except for the appsettings one. Maybe it still works but I am not sure.
Update (19 May 2021): these options are still valid for Net 5, as per Microsoft Docs, except for the appsettings one. Maybe it still works but I am not sure.
Turns out the proper way to achieve what I wanted to do, was to specifically configure Kestrel with .UseKestrel() and simply specify a single address, like this:
WebHost.CreateDefaultBuilder(args)
.UseKestrel(options => {
if (context.Configuration[WebHostDefaults.EnvironmentKey] == Environments.Development) {
options.Listen(IPAddress.Loopback, 5080); //HTTP port
}
})
.UseStartup<Startup>();
in effect overriding the default setup, and displaying this warning when Kestel starts:
warn: Microsoft.AspNetCore.Server.Kestrel[0]
Overriding address(es) 'https://localhost:5001, http://localhost:5000'. Binding to endpoints defined in UseKestrel() instead.
Note the check for development environment; in production the default ports are different (80) and without HTTPS.
if a second address is specified it will assume that address is to be secured with the built-in developer cert, as such:
WebHost.CreateDefaultBuilder(args)
.UseKestrel(options => {
options.Listen(IPAddress.Loopback, 5080); //HTTP port
options.Listen(IPAddress.Loopback, 5443); //HTTPS port
})
.UseStartup<Startup>();
you may of course specifically secure your SSL address as described here:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1&tabs=aspnetcore2x
which is necessary for production setups.
In the Program.cs, Add UseUrls as following:
WebHost.CreateDefaultBuilder(args)
.UseUrls("http://localhost:5000")
.UseStartup<Startup>();
And In The Startup.cs remove/comment the following:
app.UseHttpsRedirection();
The dotnet CLI now has a template for this.
dotnet new webapi --no-https
With ASPNET CORE 2.2, I simply set the web server URL to http not https and it picks it up on its own. I run it as a self hosted process.
Go to your project properties.
Click on the Debug tab.
Under Web Server Settings, set the URL to http://xxx
Try again :)
Turning off https lies in these 3 changes...
Properties/launchSettings.json
set sslPort to 0
remove the https url from the applicationUrl
Startup.cs
Remove or comment-out app.UseHttpsRedirection()
For Development & not in production:
in project properties disable Enable SSL
One more way for disabling https epecially is handy when docker is used.
Set enviroment variable in Dockerfile with only one HTTP url in value.
#https + http
ENV ASPNETCORE_URLS=http://+:5001;http://+:5000
#http only
ENV ASPNETCORE_URLS=http://+:5000
#joanlofe answer is excellent one, but there is also "stupid" way how one can reintroduce HTTPS on 5001 port. If you call Clear on your config sources (for proper layering of config sources for example) it means that one implicit source is gone -- "launchSettings.json" template. So if you rely on this file instead of "appsettings.json" (and by default you probably are) your app will enable HTTPS on port 5001.
My local k8s deployment was failing due to the existence of
"Kestrel": {
"Certificates": {
"Default": {
...
}
}
}
in an appsettings.json override, even after following the other steps here. If you're trying to strip a server of SSL (for example, if SSL is now terminated upstream), make sure to get rid of this configuration as well.
This seems pretty obvious now that I found it, but it still tripped us up for a few hours.
I'm trying to set a general password to my app, which means every user will have the same password to enter.
I've tried using the Project's settings - [Application.Current.Setting.Default.settingName] for the password - but then each user [in his own installed app on his PC] would have his own password, and that's not what I'm looking for.
Is there a way to set a 'general' setting to all app's instances? My project uses VSTS as well, if there's an option from there.
(I see there's a service called 'Web settings', is that it? If so, would you give me an usage example?)
Thanks!
The good way is that you can store password (can be encrypted) in the configuration file, such as app.config, web.config, then read it from configuration file before use it.
You may replace the password before deploy your app through Replace Token step (VSTS build/release)
I would like to have a workflow create a task, then email the assigned user that they have a new task and include a link to the newly created task in the body of the email. I have client side code that will correctly create the edit URL, using the entities GUID and stores it in a custom attribute. However, when the task is created from within a workflow, the client script isn't run.
So, I think a plug-in should work, but I can't figure out how to determine the URL of the CRM installation. I'm authoring this in a test environment and definitely don't want to have to change things when I move to production. I'm sure I could use a config file, but seems like the plug-in should be able to figure this out at runtime.
Anyone have any ideas how to access the URL of the crm service from within a plug-in? Any other ideas?
There is no simple way to do this. However, there is one.
The MSCRM_Config is the deployment database that handle physical deployment properties, like the URL from which users are accessing the CRM deployment. The url that you might want is the one stored in "ADWebApplicationRootDomain", in the MSCRM_CONFIG.dbo.DeploymentProperties table. You may need some permission to access this database.
Note that this doesn't work in a deployment that is an Internet Facing Deployment.
Another way could be to query the discovery service to retrieve the same information (in the case that you are on the Online edition of MSCRM4).
What do you mean by "change things"?
If you create a custom workflow assembly, you can give it a server url input. Once you register it with CRM, you can simply type in the server url when you configure the workflow. You'll have to update the url for any workflows that use the custom workflow assembly once you move to production, but you'll only have to do that once.
My apologies if this is what you meant you wanted to avoid.
Edit: Sounds like you may be able to use the CustomConfiguration attribute when you register the plugin. Here's some more info.
http://blogs.msdn.com/crm/archive/2008/10/24/storing-configuration-data-for-microsoft-dynamics-crm-plug-ins.aspx
String Url = ((string)(Registry.LocalMachine.OpenSubKey(
"Software\\Microsoft\\MSCRM").GetValue("ServerUrl"))
).Replace("MSCRMServices", "");