I'm currently using the Qt-Installer-Framework to create a setup for my application. Everything works fine for now except one thing:
If I install it to any location but C:\Program Files\MyApp, the installer won't create the registry entry for Programs and Features!
Is there a way to tell the installer to always do this?
Edit:
After trying out vairous different combinations, I do know now where the problem comes from:
If I try to install as current user only (set the AllUsers variable to false), it will always work and create an entry in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}.
If I install for all users, however, it will try to create a key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}. This will only work, if the installer has to elevate it's operations during installation (because I chose a directory I need admin rights for).
So, the error is: The installer won't elevate itself to create the "global" registry entry and thus fails to create it. Any ideas on how to fix it?
Here the link which has answer to this question.
Add the following line to your component's package xml file:
#<RequiresAdminRights>true</RequiresAdminRights>#
And use this line in your script file:
#component.addElevatedOperation("Execute", "someCommand");#
instead of
#component.addOperation("Execute", "someCommand");#
There is boolean installer.gainAdminRights() to gain elevated privileges during runtime but you will have to add it to an installer script (in packages meta directory) something alike
function Component()
{
if (!installer.isInstaller())
{
if (allUsers && installer.gainAdminRights())
{
//Set registry global
} else {
//Set registry local
}
}
}
Related
I have experienced certain problems when using libraries in premake4 scripts.
1) When creating a shared library (.dll) on Windows 10 using a premake4 script, it creates the dll fine, but it also creates a static library of small size (2K).
In my case, I was creating a shared library named MathLib.dll using a premake4 script. It did that correctly, but it also created a file named libMathLib.a of size 2K. (It may be empty.)
I don't see why there was a need for the Makefile generated by premake4 to create libMathLib.a, when in fact the objective was to create a .dll file. I think this may be a premake4 bug and I have raised it on the premake4 Issue tracker on github.
The premake4 lua script is as follows:
-- Dir : Files > C > SW > Applications > Samples >
-- premakeSamples > premake-sharedlib-create
--#!lua
-- A solution contains projects,
-- and defines the available configurations
solution "MathLib"
configurations { "Debug", "Release" }
-- A project defines one build target
project "MathLib"
kind "SharedLib"
language "C++"
files { "**.h", "**.cpp" }
includedirs {"../../../ProgramLibraries/Headers/"}
-- Create target library in Files > C > SW >
-- Applications > ProgramLibraries
targetdir "../../../ProgramLibraries/"
configuration "Debug"
defines { "DEBUG" }
flags { "Symbols" }
configuration "Release"
defines { "NDEBUG" }
flags { "Optimize" }
-- Register the "runmakefile" action.
newaction
{
trigger = "runmakefile",
description = "run the generated makefile to create the executable using the default ('debug' config)",
execute = function()
os.execute("make")
end
}
-- Register the "runmakefilerelease" action.
newaction
{
trigger = "runmakefilerelease",
description = "run the generated makefile to create the executable using the 'release' config)",
execute = function()
os.execute("make config=release")
end
}
2) The above problem is more serious than it sounds. Supposing I had already created a genuine static library named libMathLib.a in the Libraries dir, using a separate premake4 script. Subsequently, if I also create a shared library named MathLib.dll in the same directory as the static library, a dummy static library (possibly empty) would be created and replace the earlier genuine static library.
3) -- EDIT -- : I had reported this point (use of a static library) as a problem, but it has started working now. I don't know the reason, but the only difference, as far as I am aware, is that I had shut down and restarted my PC (and therefore my MSYS session on Windows 10). Therefore I am deleting this point.
How can I solve the above 2 problems?
That's the import library. You can turn it off with Premake's NoImportLib flag.
flags { "NoImportLib" }
I get this error when I create a new module:
"Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Sangeeta_Octan data: current version - none, required version - 0.0.1";i:1;s:1781:"#0
I searched on google and found no solution other than reinstalling Magento. Such as:
version has been changed from "2.0.0.0" to "2.0.0" during development,
so update tool can't recognize that "2.0.0.0" <= "2.0.0". Please,
re-install your application from scratch to get latest version. `
Do I have any options apart from reinstalling?
Change the setup_version of your module (Sangeeta_Octan) in
app/code/Sangeeta/Octan/etc/module.xml. Try a different version
name like setup_version="2.0.1" or setup_version="3.0.0"
Run bin/magento setup:upgrade
If that doesn't work, disable your module by changing your module name in app/etc/config.phpfrom Sangeeta_Octan => 1 to Sangeeta_Octan => 0. Then run bin/magento setup:upgrade
I hope below solution also solve your problem.
https://magento.stackexchange.com/questions/112293/mysql-error-and-possible-duplicates-running-bin-magento-setupupgrade-after-rena/112299#112299
in mysql find the table setup_module It will have 3 fields. Find the NULL values in data_version & have them match the schema_version
As an alternative, you can access your magento database and look at the table setup_module
You will see a list of all installed modules and you can manually set the schema/data version numbers here.
Delete the offending rows from the setup_module table (if they are there) and run the command bin/magento setup:upgrade from your Magento 2 root directory.
This is happens because of something wrong while running "bin/magento setup:upgrade" and the data_version in Module versions registry is null. It is loaded from DB, We can just proceed by manually changing it in db.
Go db via php myadmin and check "setup_module" table, the
data_version which are mentioned "null".
Login to Mysql database => then update table setup_module of the "data_version" column same as "schema_version"
I'm trying to deploy an ASP.NET web application to Azure. It's hybrid Web Forms, MVC, and WebAPI, and there are a TON of aspx/ascx files, such that they really need to be precompiled or every deploy will render the site sluggish for awhile.
I am trying to deploy via SCM integration with GitHub via kudu, with precompiled views, all merged to a single assembly.
Note that:
Deploy works fine with precompilation disabled.
Deploy works fine from Visual Studio
Build works fine if I copy the msbuild command from the Azure log, replace the relevant paths, and run it locally on my Windows 8.1 machine.
I've set up the Advanced Precompile settings as:
Don't allow precompiled site to be udpatable
Don't emit debug information
Merge all pages and control outputs to a single assembly = AppViews.dll
Here's the .deployment file for Azure
[config]
project = WebSite/WebSite.csproj
SCM_BUILD_ARGS=/p:Configuration=Release;PublishProfile=azure-prod /v:n
You notice I'm sending the verbosity /v to "normal" for extra diagnostic information.
Here is info I get toward the tail of the deployment log:
AspNetPreCompile:
D:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v \ -p D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\Source -c D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir
GenerateAssemblyInfoFromExistingAssembleInfo:
Creating directory "obj\Release\AssemblyInfo".
D:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /out:obj\Release\AssemblyInfo\AssemblyInfo.dll /target:library Properties\AssemblyInfo.cs
AspNetMerge:
Running aspnet_merge.exe.
D:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\aspnet_merge.exe D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir -w AppViews.dll -copyattrs obj\Release\AssemblyInfo\AssemblyInfo.dll -a
aspnet_merge : error 1003: The directory 'D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir' does not exist. [D:\home\site\repository\WebSite\WebSite.csproj]
Done Building Project "D:\home\site\repository\WebSite\WebSite.csproj" (Build;pipelinePreDeployCopyAllFilesToOneFolder target(s)) -- FAILED.
Build FAILED.
It looks like aspnet_compiler.exe runs, but doesn't do what it's supposed to, which is why the TempBuildDir directory (supposed to be the output of the compiler) does not exist in time for the AspNetMerge target. Contrast that with my system, where that directory DOES in fact exist, containing the marker aspx/ascx/etc. files, static content, a PrecompiledApp.config file, and a whole mess of stuff in the bin directory.
aspnet_compiler.exe has an -errorstack flag but it's not clear to me how I could get MSBuild to add this just via the .deployment file, or even if that app is really even throwing an error.
I could just deploy via Visual Studio, but I would really like to take advantage of the SCM integration so I can just push to my prod branch and let it go. Any suggestions?
I replied on https://github.com/projectkudu/kudu/issues/1341, but copying my answer here in case someone lands here...
Way back, we had found that aspnet_compiler.exe was not working within Azure Websites due to how it dealt with the profile folder. We made a change at the time that's a bit of a hack but got us going: we turned it into a no-op, by pointing HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\aspnet_compiler.exe to our own dummy exe (D:\Program Files (x86)\aspnet_compiler\KuduAspNetCompiler.exe).
But trying it now, it appears to work correctly today, likely thanks to improvements in the Azure Websites hosting environment. So we will try getting rid of this hack and doing a full test pass to make sure it doesn't cause any major regressions. If all goes well, we can get that into production, which should enable those scenarios.
In the short term, you may be able to work around this by having your build script:
copy aspnet_compiler.exe from D:\Windows\Microsoft.NET\Framework\v4.0.30319 into your own site files, but under a different name (e.g. aspnet_compiler2.exe)
convince msbuild to use that one
Note: This GitHub issue on projectkudu will eventually make this solution obsolete, but for the meantime, that issue is filed as Backlog, and this works right now.
Thank you thank you David Ebbo. With this information, I was able to bootstrap my build to work for the short term.
First, I downloaded the aspnet_compiler.exe from the Azure instance using the Diagnostic Console available at https://{WEBSITE_NAME}.scm.azurewebsites.net/DebugConsole and added that to my own repository. This way there's no question about any difference between 32/64-bit, etc. I renamed it to azure_aspnet_compiler.exe in my repository.
Second, the AspNetCompiler task doesn't give you the option to change the tool name. It's hardcoded, but as a virtual property so it's overrideable. So I had to create my own task class, and package it in its own assembly, which I built in Release mode and also included in my repository.
public class AzureAspNetCompiler : Microsoft.Build.Tasks.AspNetCompiler
{
private string _toolName = "aspnet_compiler.exe";
protected override string ToolName
{
get { return _toolName; }
}
public string CustomToolName // Because ToolName cannot have a setter
{
get { return _toolName; }
set { _toolName = value; }
}
}
Next I needed to replace the AspNetPreCompile task in MSBuild, but I couldn't figure out how to do that directly. But that task wasn't doing anything anyway, so why not just run right after it?
I added this to the top of my Website.csproj file to import the DLL containing the AzureAspNetCompiler class. Note that the path is relative to the Website.csproj file I'm editing.
<UsingTask TaskName="AzureBuildTargets.AzureAspNetCompiler"
AssemblyFile="..\DeploymentTools\AzureBuildTargets.dll" />
Then I added this right below it, which is basically stealing the MSBuild target definition of AspNetPreCompile from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets, with some of the property setting stuff near the top of it left out (because the original task will do that for us anyway.) Just take note of the ToolPath and CustomToolName values at the bottom of the (renamed) AzureAspNetCompiler element.
<PropertyGroup>
<!--Relative to solution root apparently-->
<LocalRepoDeploymentTools>.\DeploymentTools</LocalRepoDeploymentTools>
<AzureAspnetCompilerPath>$([System.IO.Path]::GetFullPath($(LocalRepoDeploymentTools)))</AzureAspnetCompilerPath>
</PropertyGroup>
<Target Name="NoReallyAspNetPreCompile" AfterTargets="AspNetPreCompile">
<AzureAspNetCompiler
PhysicalPath="$(_PreAspnetCompileMergeSingleTargetFolderFullPath)"
TargetPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)"
VirtualPath="$(_AspNetCompilerVirtualPath)"
Force="$(_AspNetCompilerForce)"
Debug="$(DebugSymbols)"
Updateable="$(EnableUpdateable)"
KeyFile="$(_AspNetCompileMergeKeyFile)"
KeyContainer="$(_AspNetCompileMergeKeyContainer)"
DelaySign="$(DelaySign)"
AllowPartiallyTrustedCallers="$(AllowPartiallyTrustedCallers)"
FixedNames="$(_AspNetCompilerFixedNames)"
Clean="$(Clean)"
MetabasePath="$(_AspNetCompilerMetabasePath)"
ToolPath="$(AzureAspnetCompilerPath)"
CustomToolName="azure_aspnet_compiler.exe"
/>
<!--
Removing APP_DATA is done here so that the output groups reflect the fact that App_data is
not present
-->
<RemoveDir Condition="'$(DeleteAppDataFolder)' == 'true' And Exists('$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data')"
Directories="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data" />
<CollectFilesinFolder Condition="'$(UseMerge)' != 'true'"
RootPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)" >
<Output TaskParameter="Result" ItemName="_AspnetCompileMergePrecompiledOutputNoMetadata" />
</CollectFilesinFolder>
<ItemGroup Condition="'$(UseMerge)' != 'true'">
<FileWrites Include="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\**"/>
</ItemGroup>
With this in place, everything works as I would expect it to.
My current project is at https://github.com/jimmack1963/localPackages.git.
I am trying to get this code to work:
console.log("You pressed the button, " + MyName);
where MyName comes from a package called simple, that is JUST LOCAL. Per 6.5, am exporting via
Package.on_use(function (api, where) {
api.add_files(['constant.js'], 'client');
//below added per possible suggestion from Nathan, had no effect.
api.use('constant.js', 'client');
if (api.export)
api.export('MyName');
});
Am trying to factor my code out to local packages. This is not about publishing packages, but about using local ones, which is referred to in many places. My package is simply trying to publish a string, MyName. But the project wants none of it. "MyName is not defined."
I copy the technique in 'Discover Meteor,' but it doesn't work for me, and I try other things. Have had a lot of success in Meteor in general.
This spec seems to be changing. I get the 6.5 export requirement, but easily find contradictory advise about the base project's need to add that project in smart.json (not the one in the package). Most references don't list that as a requirement at all.
I've tried
{
"packages": {
"simple" : {
"path": "packages/simple"
}
}
}
and putting it into git and trying from a different project:
{
"packages": {
"simple" : {
"git": "https://github.com/jimmack1963/localPackages.git"
}
}
}
For the latter, pleasingly, the installer was smart enough to burrow down and extract the package itself, ignoring the project wrapping it in the git project. Nice! So, I have the same problem when I install the package directly from git, still not published to the world.
Ubuntu 13.04
Meteorite version 0.6.11
Meteor Release 0.6.5.1
I had the same issue after migrating to 0.6.5 -
You only get 'exported' variables from packages you explicitly "use"; Packages "use" other packages by calling .use inside Package.on_use, projects "use" packages by adding them to .meteor/packages
Additionally, it seems to be quite picky about exporting variables, and wont currently export ones preceded with this.
I'm trying to change the path for the user profile pictures in a Drupal 7 installation and I'm getting the following error:
The directory public://public://user-pictures does not exist or is not
writable.
The path that I'm entering is simply "user-profiles".
I tried resetting the variable stored in the database by using the value from a new installation:
UPDATE variable
SET value=0x733A313A2231223B
WHERE name = 'user_pictures';
The update was successful but the problem remained.
Does anybody know how to correct this or where this value is stored in the database?
Thanks
user_pictures is a boolean variable, you're probably looking for user_picture_path.
Since variable values are stored in serialised PHP arrays it'll be much easier to update that path using the API:
variable_set('user_picture_path', 'user-profiles');
Similar to Clive answer, you can use drush from the command line :
drush vset user_picture_path your_path
I got the same error and am able to solve the issue.
“public://public://user-pictures does not exist” when trying to change user profile photo path."
What is did: Navigated to mysite.com/admin/config/people/accounts
in 'Picture directory' field default value was 'pictures', i have changed the directory name to my custom directory name 'prof_images' and now when i try to save the settings, i started getting the above error. I have cross checked the Directory name and permission but everything was fine.
How i solved the issue:
Navigated to Drupal core modules folder /modules/user and commented the following lines:
Blockquote
if (!file_prepare_directory($picture_path, FILE_CREATE_DIRECTORY)) {
form_set_error('user_picture_path', t('The directory %directory does not exist or is not writable.', array('%directory' => $picture_path)));
watchdog('file system', 'The directory %directory does not exist or is not writable.', array('%directory' => $picture_path), WATCHDOG_ERROR);
}
Blockquote
After clearing the cache, everything went cool.
Navigated to mysite.com/admin/config/people/accounts and set 'prof_images' as my user image directory and saved the settings. This time my settings are saved without any problem.
Then uncommented the above lines in the user module and everything worked as usual.
Hope this will help someone.
Thanks