I'm getting this message spammed in the console:
Additionally, my extension doesn't show up in System Preferences:
(no, I'm not developing OneNote)
Here are the commands I use to install the extension, each of which claims it succeeded:
And here is proof that the extension is indeed sandboxed:
The only possible problem I can imagine involves our code signing process. For various reasons, it's codesigned after it's compiled, using a command like the following:
codesign --force --entitlements "$ENTITLEMENT" --sign "$CODESIGN_ID" --deep "$APPEX_PATH"
This is a requirement and, sadly, cannot be bypassed. Codesigning must be done after the appex artifact is generated.
However, this has not been a problem in the past. This is the say it's been done for a while and it worked fine. The only difference I can think of is that now we are bundling in two new .frameworks... but those are signed as well, so I'm not sure what to do.
When I remove the frameworks from the project and move codesigning to Xcode, it works... but that's not a permanent solution since we still need to manually codesign later on in our process.
What can I do to get this extension installed and preserve our codesigning requirement?
Related
I just started experimenting with the .NET framework and I noticed that when I run:
dotnet list packagein the JavaScript Debug Terminal of VS Code I get all my packages as I should but they have strange Links attached to some of them that lead to scam sites.
ex:
> Windows.EntityFrameworkCore.SQlite --> ww1 .entityframework.com which is a shitty site pretending to be .NET hiring developers.
....
enter image description here
I tried running anti virus scans and cleanups. Nothing detected.
I tested on PowerShell, GitBash and Cmd terminals. Nothing, only happens in the JavaScript Debug Terminal
I tried disabling all my VS Code extensions (including the built-in ones) except the JavaScript debugger to see if its coming form another extension. Still there.
I have heard of extension vulnerabilities and VS Code Hacks but this is a built-in plugin.
Has this happened to anyone?
VSCode is configured to attempt to parse strings from any output that could represent a valid URL and present the option to you as a clickable link for convenience.
Since .tools is a valid TLD, it thinks the string Microsoft.EntityFrameworkCore.Tools is referencing the URL http://microsoft.entityframeworkcore.tools/ which it seems has been parked by an unscrupulous individual or organization. You as the developer should understand that this is a namespace reference and not a URL, and thus there is no value in clicking it.
This is not indicative of any sort of malware or any real malfeasance.
I was trying to make changes to a module. I couldn't get the site to seem to reflect those changes. I thought I could possibly disable the feature, and re-enable the feature and it would force whatever module caching is happening to reload the module. However, it broke the site entirely, and now I can't even enable the feature from the orchard.exe command line tool. I am getting the same error. It's basically Autofac complaining that it can't find a type that was part of the feature. However, if the feature is removed, I am not sure where/why it is still trying to load.
Exception :
None of the constructors found with 'Orchard.Environment.AutofacUtil.DynamicProxy2.ConstructorFinderWrapper' on type 'RCAM.Products.Drivers.FeaturedProductsWidgetPartDriver' can be invoked with the available services and parameters:
Cannot resolve parameter 'RCAM.Products.Services.IProductService productService' of constructor 'Void .ctor(RCAM.Products.Services.IProductService)'.
I cannot get in the admin portal to re-enable the feature. I cannot use the command line tool. I tried setting the [Settings_ShellFeatureStateRecord] to Up in the database, but that didn't change anything at all. It must be file driven as well as database persisted.
This is a production site and is currently down. Any help you can give would be greatly appreciated.
Your question doesn't make it clear if you changed the code directly on your production site or if it crashed after a proper deployment, so here are my two cents:
If you make changes to your module in a live environment you should delete the contents of your App_Data/Dependencies-Folder afterwards. No need to re-enable the module.
This will only work, if you haven't disabled the Dynamic Module loader, which should be done though in a production environment.
Otherwise, make sure your module actually compiles. You should probably add your Module to Orchard.Webs build dependencies to make sure it actually re-compiles every time you run Orchard on your dev machine.
For removing the feature, instead of just disabling it, it should be enough remove your module folder and delete YourModule.dll from App_Data/Dependencies
I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.
I am currently trying to implement a one-click build solution (without having to start the monodevelop IDE) for my monotouch projects, where i could specify provisioning profiles and code signing certificates. I searched popular build tools like nant, ant and maven, but none seems to support monotouch. Has anyone tried something similar ?
I've gotten it work with Jenkins (aka Hudson).
You basically setup a Jenkins server, and setup your Mac as a "slave" build server. (I used a JNLP slave).
From there you can run any command line you want in the build, so you merely have to run mdtool with some arguments, like so:
/Applications/MonoDevelop.app/Contents/MacOS/mdtool -v build "--configuration:Release|iPhone" "Path/To/YourSolution.sln"
One thing to worry about is that to sign an iOS app, the slave process must run under your user. So you can't really create a Mac daemon for it, you'll have to run the slave process in startup for your user and minimize it, which is kind of annoying.
You tried teamcity? Might be worth you having a look at this thread Buildserver for MonoTouch upon OS X?
Thx for your answers. However i don't need to use such heavy artillery in this case. Since i'm developping a single and small app, I ended up by creating 3 different Build configurations in my solution, because i found out that it is possible to configure different codesign identities and provisioning profiles for each one (Development, Ad-Hoc, AppleStore), in the monodevelop project options menu.
Then in the AppleStore/Ad-Hoc configuration, i added post build commands, so i could create the .ipa file automatically (basically create a "Payload" folder and copy the .app file into it, and then zip it into a .ipa file, along with the icon and itunesartwork files).
Finally i created a bash script that invokes mdtool with any of the configurations, so i can build and generate .ipa executables by just executing the script.
I've already asked similar question on this issue on stack overflow already, but I believe this part of the issue can be separated into a new question.
I've not done mobile development before so the use of signing and certificates is a new concept to me, and for all the reading of topics I have done, its not really improved my knowledge as each website I read talks only about a small part of signing, not the complete process, and piecing it all together has been difficult.
The issue I have is my driver is not been loaded at startup on WM6.1. Its a driver for GPS so needs to be loaded so its available to any GPS software accessible on a COM port. I believe this is due to a signing issue, given that the DllMain method is never called.
I have been given a privileged certificate (.pfx) to use, and for the record have also got the new (Jan 2010) SDKSamplePrivDeveloper certificate as well. I assume a privileged certificate is needed for drivers.
So what have I actually done. I've tried atleast several variations on this over the last 4-5 days all with no success.
In visual studio;
1)The DLL project has authenticode signing set to our .pfx certificate. Build the project.
2)The CABWizard project has authenticode set to the same certificate. Build the project.
3)Following the MSDN instructions... Converted the .pfx into a 509 Base64 Certificate, and created an XML provisioning file from it.. It has been created into its own CAB Or CPF file. And also tried provisioning the _setup.xml file into the previously created CAB file so its installed with the application.
4)I have installed these onto the device, and whilst the driver does work in our test app it does not load at boot even though its registry settings in "BuiltIn" are correct. When checking the certificate stores in the registry I can see the certificate added to the SPC, Root, Privileged and Unprivileged stores. And when using System|Certificates I can see the certificate in Root tab. So they have definitely been added.
Given the above did not work. I have also tried the siggner.exe tool from http://www.modaco.com/content/i8000-verizon-sch-i920-omnia-ii-http-i8000-modaco-com/306870/sdkcerts-2010-and-signing-tool/ with the SDKSamplePrivDeveloper certificate.
1)The Dll project has authenticode signing set to No. Build the project.
2)Load up siggner.exe and sign the Dll file with SDKSamplePrivDeveloper.cer.
3)The CABWizard project has authenticode set to No. Build the project.
4)Load up siggner.exe and sign the cab file with SDKSamplePrivDeveloper.cer.
5) Use NewSDKCerts.Cab to install the SDKSamplePrivDeveloper certificate into the stores.
6) Install the CAB file i created with the driver.
7) Again, on a warm reboot the driver is not loaded at boot into device.exe.
Given the above, can anyone give me some clear instructions on a sure fire way to load the driver at startup. I'm obviously doing something wrong with the signing given this does boot up without an issue in Windows CE5. I know the device driver code is OK as I can activate it manually in code with ActiviateDevice() method in WM6.1.
Edit--
It maybe worth adding, I also created a DLL and CAB with no signing at all. And on a clean boot of the OS it installed without complaining. Whilst still not loading at boot I did expect warnings about the CAB and DLL been unsigned.
The reason for driver failure, was not a certificate issue.
The driver was originally self contained and also contained some GUI code, and has since expanded. A library used to make the application full-screen was not available at start up so it silently failed with a dependency issue.
This has currently been resolved with a start-up application loading later to wake up the driver, once the library is available. A proper solution to be added is late loading of the required library to prevent a dependency failure.
Driver signing was also an issue in a related matter with this driver. We now have a certificate from the manufacturer to sign drivers so that issue was resolved as well.