I finally have ccrewrite working, and my unit tests are passing, but when I publish a web project, it keeps blowing up as if it hadn't been rewritten. After checking with JustDecompile, the code hasn't been rewritten:
Contract.Requires<ArgumentNullException>(log != null, "Must provide a valid ILog to UmbracoServiceProvider");
Contract.Requires<ArgumentNullException>(contentService != null, "Must provide a valid IContentService to UmbracoServiceProvider");
Contract.Requires<ArgumentNullException>(examineManager != null, "Must provide a valid ExamineManager to UmbracoServiceProvider");
The above should be __ContractsRuntime... if it had been rewritten.
Suggestions?
When publishing, it was building the 'Release' configuration, which has it's own set of code-contract settings which I hadn't set up yet.
Related
Someone can tell me if I can add var on project name please ?
project = "${var.env}"
error output when using waypoint init
[xxxx#xxxx finess-api]$ waypoint init
❌ Error loading configuration!
! /home/xxxx/waypoint.hcl:2,25-28: Unknown
variable; There is no variable named "var"., and 1 other diagnostic(s)
! Project had errors during initialization.
Waypoint experienced some errors during project initialization. The output
above should contain the failure messages. Please correct these errors and
run 'waypoint init' again.
variable env {
type = string
default = ""
}
Thx
It's not possible to template the project name; however instead of templating the project name, I recommend using workspace-scoped operations, with one workspace for each "env" you're using.
https://developer.hashicorp.com/waypoint/docs/lifecycle/scope
A POCO request. I have a situation where a directory cannot be deleted (access rights), but the content is mine. I can call Poco::File .remove(true) on this directory which does indeed delete all the content of the directory, but the call always throws an exception as the dir itself cannot be deleted. So I have to frustratingly parse through the directory and remove each item individually. A simple "preserve the top level directory" parameter would make my day.
If anyone hears this and agrees, thanks!!
I have used an ARM Template to deploy a Microsoft.Maps/account resource to Azure.
That was successful:
Resource Microsoft.Maps/accounts 'nzmoebasedemo0000bt' provisioning status is succeeded
I'd like to retrieve the Primary key generated, within the ARM template, in order to persist it to a KeyVault.
I looked in https://resource.azure.com but the Maps/account provider was not listed, so could find no hint as to what property to read.
I tried:
[listKeys(resourceId('Microsoft.Maps/account', 'parameters('keyVaultVaultSecretMapsAccountResourceName')'), providers('Microsoft.Maps', 'account').apiVersions[0]).keys[0].value]"
Abd got back:
#{parameters=; status=Trial run failed. ; outputs=; provisionStateSucceeded=False; deploymentOutput=; errorCode=InvalidTemplate; errorMessage=Deployment template validation failed: 'The template resource 'azure.arm.base.keyVault.vault.secret' at line '168' and column '9' is not valid: Unable to evaluate template language function 'providers': function requires the second argument to be a multi-segmented resource type excluding the resource provider namespace. Invalid function argument 'account'. Please see https://aka.ms/arm-template-expressions/#providers for usage details.. Please see https://aka.ms/arm-template-expressions for usage details.'.}
Which in this case...seems incorrect.
What am I not seeing/getting?
Thanks!
Edit:
As per suggestion given, the following did pass a test run.
"[listKeys(resourceId('Microsoft.Maps/account', parameters('keyVaultVaultSecretMapsAccountResourceName')), '2018-05-01').keys[0].value]"
But when actually run, got the following:
1:02:35 AM - Resource Microsoft.Maps/account 'nzmoebasedemo0000bt' failed with message '{
"error": {
"code": "InvalidResourceType",
"message": "The resource type could not be found in the namespace 'Microsoft.Maps' for api version '2018-05-01'."
}
}'
Edit again:
As per guidance given in the comments, the following works! (after correcting api version, spelling mistake, and using 'primaryKey' property:
"[listKeys(resourceId('Microsoft.Maps/accounts', parameters('keyVaultVaultSecretMapsAccountsResourceName')), '2018-05-01').primaryKey]"
So the problem was due to a typo, the provider\resource is Microsoft.Maps/accounts
Is there any way of preventing users being dropped when publishing a DACPAC using SqlPackage.exe, other than changing the setting below, which prevents all objects from being dropped if they're not in the DACPAC.
<DropObjectsNotInSource>True</DropObjectsNotInSource>
We deploy to a number of environments, each with different users. Current workarounds are to either:
Script the users for each environment to recreate them after deploying
Use /Action:Script and manually change the deployment script.
Neither of these are ideal though...
Use SqlPackage.exe parameters (since February 2015 release: New Advanced Publish Options to Specify Object Types to Exclude or Not Drop):
Here's the actual parameters we use in our deployment:
/p:DropObjectsNotInSource=True
/p:ExcludeObjectTypes=Users;Logins;RoleMembership;Permissions
The first line cleans all, but the next line further refines what not to drop. This combination proved the most effective with us to drop all unnecessary objects, yet retain the login mappings as they were.
Detailed documentation of all the parameters and their possible values can be found from MSDN - SqlPackage.exe
I ran into the same issue and used Pre/Post deployment scripts to reinsert users, permissions, roles, etc like the suggested blog post. However this became unmaintainable in the long run (users unable to authenticate during deployment, if the deployment fails permissions are not restored, security changes require going through source control and re-deployment).
Recently, I reevaluated the problem as we were migrating our deployment platform. With the DacFx API (and bug fixes) released, I was able to extend the deployment process in SSDT by creating a DeploymentPlanModifier. They provide an example for filtering objects on creation, with simple modifications I filter any drops for permission based object types (using /p:AdditionalDeploymentContributors argument).
[ExportDeploymentPlanModifier( UserMappingFilter.PlanFiltererContributorId, "1.0.0.0" )]
public class UserMappingFilter : DeploymentPlanModifier
{
public const string PlanFiltererContributorId = "Dac.UserMappingFilter";
protected override void OnExecute( DeploymentPlanContributorContext context )
{
DeploymentStep next = context.PlanHandle.Head;
while( next != null )
{
DeploymentStep current = next;
next = current.Next;
DropElementStep dropStep = current as DropElementStep;
if( dropStep != null && ShouldFilter( dropStep ) )
{
base.Remove( context.PlanHandle, dropStep );
}
}
}
private bool ShouldFilter( DropElementStep createStep )
{
TSqlObject target = createStep.TargetElement;
if( target.ObjectType.Name == "RoleMembership" || target.ObjectType.Name == "User" || target.ObjectType.Name == "Role" )
{
return true;
}
return false;
}
}
We handle this in post-deploy scripts. It's a bit harder to set up, but once set up allows you to configure a slightly different script for each environment. We use this in conjunction with Publish Profiles with a different profile per environment. Basically, you use Powershell to generate a bunch of scripts for users and permissions, add those scripts to your project(s), and then Include the files in the project. Add what is referred to in the blog post as "SecurityAdditionsWrapper.sql" to your post-deploy script, and you should be good. Just remove the other security from your project to ensure that it's set correctly.
http://schottsql.blogspot.com/2013/05/ssdt-setting-different-permissions-per.html
There are also options in SSDT for:
"Drop Permissions not in source" - False
"Drop role members not defined in source" - False
"Ignore permissions" - True
"Ignore role membership" - True
We use those, but if you need better control over your users/permissions by environment, I'd strongly recommend checking out that blog post. (With thanks to Jamie Thomson for the original idea.)
This error suddenly occurred when Pressflow was added to our Drupal installation. It is coming from a custom module that, prior to Pressflow seemed to work fine. After the addition of Pressflow, running Drush causes this error to display on screen.
The function that is identified as the source of the error looks like this:
function user_search_location_get(&$user) {
if (count($user->user_location_pref)) { // This line is causing the error.
return $user->user_location_pref;
}
// …
}
The error message is the following:
WD php: Notice: Undefined property: stdClass::$user_location_pref in user_search_location_get()
Short answer, in your custom module, you should check if that property exists before you count it. That, or make sure the $user object has that property before you use it.
if (isset($user->user_location_pref) && count($user->user_locaion_pref) > 0) {
return $user->user_locaion_pref;
}
While it is a little more work, when you start developing with notices turned on, you will find errors in your code that otherwise would have not appeared till later, and would have been more difficult to track down.
In your previous environment or install, the PHP error reporting was probably set to not show notices. While I recommend keeping notices on and making your code work with them, you can turn them off through the Drupal 7 UI. Configuration -> Development -> Logging and Errors. Then set the value to 'Errors and Warnings' ... Otherwise, you can set your error reporting level in your php.ini to report all except notices.
Note that Drupal 6 did not force notice reporting on, while Drupal 7 does. That prompts this type of question a lot.
If this is your only notice issue though, it makes more sense to just correct your custom module.