I'd like to install liip/imagine-bundle in my symfony 2 project. But in order to make barcodes, I installed previously MopaBarcodeBundle.
MopaBarcodeBundle requires "avalanche123/imagine-bundle" which requires imagine/imagine: v0.4.1
And
LiipImagineBundle requires imagine/imagine: ~0.5,<0.7
Obviously composer detects the conflict, as he cannot unistall v0.4.1, and that version is not enough for LiipImagine.
I'd like to know how I could bypass this. Create sorts of aliases in composer and keep the two versions on my project ? I'm not a pro in version management, so I guess this is not possible.
Thank you very much for any help.
Ok, after some code inspection i figured out a way around. MopaBarcodeBundle doesn't really requires avalanche123/imagine-bundle, but it uses it in the service declaration. (To make the link with Imagine classes).
So I changed the service.xml file containing the BarcodeService declaration.
<parameter key="imagine.gd.class">Imagine\Gd\Imagine</parameter>
<service id="imagine" alias="imagine.gd" />
<service id="imagine.gd" class="%imagine.gd.class%" />
I guess thoses lines could be factorised, but i chose to keep it as it was done in avalanche123.
Also a constant from avalanche was used in 5th argument, I changed it to :
<argument>%kernel.root_dir%../web</argument>
Finally I removed avalanche, and then install a newer version of imagine/imagine
Related
As part of installation of a WPF application using .NET 6 and a WiX installer, I would like to check whether the .NET 6 runtime is installed.
WiX provides pre-defined properties to check this for .NET framework but nothing for .NET Core and beyond so I am attempting to check for the presence of a registry key.
There is a registry key that can be checked under: HKEY_LOCAL_MACHINE\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedhost\Version
However, if I uninstall the runtime the registry key does not get removed, is there any other reliable way to check whether the runtime is installed, as well as which version is installed?
WiX 3 currently doesn't handle this natively. It is being worked on for WiX v4 (GitHub issue). Reading the issue led me to these tools as a current workaround.
https://www.nuget.org/packages/Microsoft.NET.Tools.NETCoreCheck.x86
https://www.nuget.org/packages/Microsoft.NET.Tools.NETCoreCheck.x64
You can use the files inside of these packages to check for a runtime. Either by running NetCoreCheck.exe directly or using the custom action DLL provided.
NetCoreCheck.exe -h to see help. But you'll want something like this:
netcorecheck --runtimename Microsoft.NetCore.App --runtimeversion 6.0.0
I don't know how to use the custom action dll but I do see it has two DLL exports.
ordinal hint RVA name
1 0 00001500 CheckNETRuntime
2 1 00002260 get_hostfxr_path
You may use the Custom Action DLL mentioned in Hank's answer if you want to integrate this in your WiX project.
You can use the NuGet package to obtain the dll.
Unfortunately there seems to be no documentation in existence for this DLL, so I used the source code to figure out how this works.
First you need to define a few properties that are used as input parameters for the .NET runtime check, and for the result of the check.
<Property Id="CheckNETRuntime_Framework" Value="Microsoft.AspNetCore.App" />
<Property Id="CheckNETRuntime_Version" Value="6.0.0" />
<Property Id="CheckNETRuntime_Result" />
CheckNETRuntime_Framework is the framework to search for. There are currently 3 options:
Microsoft.NETCore.App
Microsoft.AspNetCore.App
Microsoft.WindowsDesktop.App
CheckNETRuntime_Version is the version of .NET to look for.
The result will be stored in CheckNETRuntime_Result. A value of 0 indicates the runtime was found, any other value indicates it was not found.
To run the custom action, do this:
<Binary Id="CustomActions" SourceFile="NetCoreCheckCA.dll" /> <!-- This should be the path to the dll -->
<CustomAction Id="CheckRuntime" Return="ignore" BinaryKey="CustomActions" DllEntry="CheckNETRuntime" />
<InstallExecuteSequence>
<Custom Action="CheckRuntime" Before="LaunchConditions" />
</InstallExecuteSequence>
<InstallUISequence>
<Custom Action="CheckRuntime" Before="LaunchConditions" />
</InstallUISequence>
Note: you need to add Return="ignore" if you do not want the installer to fail when the runtime was not found (as the return value if not 0, which indicates a failure).
The CheckNETRuntime_Result property can be used elsewhere in your setup, for example you could use it in a condition:
<Condition Message=".NET 6 runtime is not installed">
<![CDATA[CheckNETRuntime_Result=0]]>
</Condition>
I installed the following packages on a symfony 2.8 project because I want to upgrade to version 3.4 to take advantage of the LTS
"propel/propel-bundle" : "4.0.x-dev",
"propel/propel" : "2.0.x-dev",
I search how to declare a behavior, before I was on version 1 of Propel, and to declare a behavior, it was enough to do that in the config.yml :
behaviors:
my_behavior: MyBundle\MyBehavior
The problem is that this configuration does not work anymore with the version 2, I can not find quite precise documentation on how to declare a propel behavior because the goal here is to then use it in the schema.xml like this :
<behavior name="geo_location"></behavior>
The goal is to run : propel:model:build but when I run this command, I get this error message :
Unrecognized option "behaviors" under "propel.database"
Have a look at this manual page. Long story short, you have to create a composer package with the type "propel-behavior" to be able to use your behavior in your project.
If you are having trouble, figuring it out, look up some existing behaviors on github to see how it is done.
Examples of cusotm behaviors can be found here.
I have a solution that includes three web projects (as well as a lot of class library projects). The web projects all use Web.config transforms to specify per-environment configuration.
I have Web.config transforms for multiple build profiles, named Web.UAT.config, Web.Staging.config and Web.Release.config
I am building and deploying the project from my CI server using MSBuild with the following arguments:
/t:Clean,Build /p:Configuration=UAT;DeployOnBuild=True;PublishProfile=UAT
For exactly one of the three projects, the web.config transforms appear to get applied twice, with elements marked xdt:Transform="Insert" appearing twice. Looking in the build output, it seems that all three projects run the following targets:
PreTransformWebConfig
TransformWebConfigCore
PostTransformWebConfig
PreProfileTransformWebConfig
But the problematic project also runs these targets (immediately after those listed above):
ProfileTransformWebConfigCore
PostProfileTransformWebConfig
The .csproj files for web projects include the following by default:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
This file in turn imports \Web\Microsoft.Web.Publishing.targets, also under the VSToolsPath (on my dev machine, this corresponds to C:\Program Files (x86)\MSBuild\VisualStudio\v12.0).
The interesting segment of this file looks like the following:
<ProjectProfileTransformFileName Condition="'$(ProjectProfileTransformFileName)'=='' And '$(PublishProfileName)' != '' ">$(_ProjectConfigFilePrefix).$(PublishProfileName)$(_ProjectConfigFileExtension)</ProjectProfileTransformFileName>
<!--if $(TransformWebConfigEnabled) is also enabled and the ConfigTransform and ProfileTransform happen to have same filename, we default $(ProfilefileTransformWebCofnigEnabled) to false so it doesn't do double transform-->
<ProfileTransformWebConfigEnabled Condition="'$(ProfileTransformWebConfigEnabled)'=='' And '$(TransformWebConfigEnabled)' == 'true' And ('$(ProjectProfileTransformFileName)' == '$(ProjectConfigTransformFileName)')">False</ProfileTransformWebConfigEnabled>
The double transform was happening as a result of ProfileTransformWebConfigCore running, which is conditional on ProfileTransformWebConfigEnabled, which only defaults to false if the ProjectProfileTransformFileName and ProjectConfigTransformFileName are equal.
I added the following target to all three of my projects:
<Target Name="DebugWebConfigTransform" AfterTargets="PreProfileTransformWebConfig">
<Message Text="ProjectProfileTransformFileName: $(ProjectProfileTransformFileName)"/>
<Message Text="ProjectConfigTransformFileName: $(ProjectConfigTransformFileName)"/>
</Target>
For the problematic project, this target output the following:
DebugWebConfigTransform:
ProjectProfileTransformFileName: Web.UAT.config
ProjectConfigTransformFileName: Web.Release.config
Since these two values were different, the double transform was occuring for the reasons described above.
The reason the ProjectConfigTransformFilename was set to Web.Release.config was that the ProjectConfigurationPlatforms in my .sln file was incorrect. The .sln file's Configuration|Platform pair of UAT|Any CPU was being mapped to Release|Any CPU for this project.
I think it was actually applying the UAT and Release transforms as a result (due to the exact nature of my transforms and the order in which they were applied, this was indistinguishable from applying the UAT transform twice).
Updating the ProjectConfigurationPlatforms mapping in the solution file resolved the issue for me.
This issue was occurring for me because I had multiple projects in my solution configuration using different configurations.
It was running more than one web.config transforms because of this configuration:
After switching the projects to use the same configuration I no longer received the issues in my web.config.
It seems this can also happen if you leave off the Configuration msbuild parameter. The PublishProfile isn't good enough.
I had a different issue than all the answers. In my case, I had a profile named staging.pubxml which was using the configuration prod. On publish both the staging and the prod transformation would occur.
Turns out, the name of the .pubxml file also triggers a transform if the same configuration can be found. I simply changed the name of the file and it solved my issue.
I have a Plone site with a traditional product BaseProduct (versioned directly in the Products filesystem directory of the Zope installation); the rest of the setup is buildout-based.
For a fork of the project, I need another product AdditionalProduct, which I made the same way (I know it's not the current state-of-the art method; but that's how it worked before for me ...).
Now I was able to install AdditionalProduct using the quickinstaller (for now it contains a single skin directory with a single template only, but this will change, of course).
Sadly, this ceased to work; the product is not shown in the quickinstaller anymore. There is no visible error; I was able to pdb.set_trace() it during instance startup, and there is no error in the error.log either.
The profiles.zcml file looks like this:
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:genericsetup="http://namespaces.zope.org/genericsetup"
i18n_domain="BaseProduct">
<include package="Products.GenericSetup" file="meta.zcml" />
<genericsetup:registerProfile
name="default"
title="AdditionalProduct"
directory="profiles/default"
description="Extension profile for AdditionalProduct."
provides="Products.GenericSetup.interfaces.EXTENSION"
/>
</configure>
(Copied and changed from an earlier AdditionalProduct of another fork; I don't really understand that "meta.zcml" part.)
How can I debug this?
I'd be willing to "eggify" my product (AdditionalProduct first, since it has the problem; perhaps BaseProduct later as well), but I'm not sure about the amount of work, and a How-To would be useful ...
Your product should have a configure.zcml file that includes your profiles.zcml with the following directive:
<include file="profiles.zcml" />
Is it the case ?
You can debug this by ruling out the following:
The ZCML is not loaded (introduce a syntax error in profiles.zcml and
restart Plone to ensure profiles.zcml is loaded.)
You don't have the 'z3c.autoinclude.plugin': 'target = plone' entry point (not applicable as you are not using a Python package)
Your product is not loaded by Zope2 because it's not in the products folder, or has some related issue e.g. missing __init__.py.
Also you may not need the following, as it should already be included by Plone before your products is loaded:
<include package="Products.GenericSetup" file="meta.zcml" />
(And file='meta.zcml' means "load meta.zcml instead of the default file name i.e. configure.zcml")
Lastly, I'd recommend creating a Python package (AKA "eggify"). See the following for an overview:
http://blog.aclark.net/2015/06/01/plone-add-on-development-for-command-line-savvy-developers/
Just ran nginx::source recipe on my vagrant box, and I have very unusual behaviour.
When I include a recipe from the Vagrantfile (as below), everything works like a charm,
chef.add_recipe("project::nginx")
chef.add_recipe("nginx::source")
(project::nginx recipe is very simple. Using it to override default attributes of the nginx cookbook)
but if I include a recipe at the very end of project::nginx (mentioned up), everything falls apart:
node.default['nginx']['server_names_hash_bucket_size'] = 128
include_recipe "nginx::source"
Until now I didn't know there's any difference in behaviour between those two invocations. Does anybody here knows what's the difference?
Gotya! Chef 11 feature. Issue with it exist in chef-solo solely :)
To make a quick resume, difference is:
chef.add_recipe() - loads entire cookbook context (all the files, e.g. recipes, definitions, attributes...)
include_recipe "" - files(attributes, definitions etc.) that are not in the expended run list are not loaded.
There are at least 4 ways to solve the issue(put files in the run list):
include_attribute - include desired attribute file explicitly.
metadata.rb->dependency - if your cookbook is using recipe from another cookbook, put that cookbook in metadata.rb's dependency section, and all it's files will be loaded.
chef.add_recipe() - Load recipe via Vagrantfile. (Mentioned here just for reference)
Berkshelf - you may use this cookbook manager to solve the issue as well. Here's the Stackoverflow thread about this exact problem and some Docs
For those who are interested in further reading, Chef 11 introduced dependency-based cookbook loading for non-recipe files. The new loading logic means that files belonging to cookbooks which exist in the cookbook_path but are not in the expanded run_list or dependencies of the cookbooks in the expanded run_list will no longer be loaded. REF: Opscode breaking changes documentation, and if you need a signature of the error I got, here's the exactly same one, even for the same cause.