Vue gives me a warning about uncommited changes - vue-cli-4

so I just created a new vue project with vuecli. I played around a bit and then wanted to add a new plugin using vue add <plugin>. Now I get the following warning:
There are uncommited changes in the current repository, it's
recommended to commit or stash them first.
What's that about? Why does this error message use this specific terminology? I'm not using any versioning system, since I'm just playing around and even if I would - that warning would still confuse me. Does vue-cli use some kind of internal versioning system?

I realise this is 6months+ old, but I ran into the same issue.
I am using vue-cli inside MS Studio Code. It appears that Code has a "Source Control" support which (for me) is using git. I didn't configure this directly - I assume that Code found git when it installed and enabled it for me.
I believe that vue-cli detects any uncommitted changes (based on this) in the underlying source code control mechanism.
For me - using MS Studio Code > Source Control (as per picture attached) allowed changes to be staged and vue-cli install to proceed without the warning.
Edit:
It appears (for me) that vue is adding the git integration on project creation - below is default from vue ui. Which I believe is where vue-cli is detecting unstaged changes.

Related

Xcode failed to load #rpath/libvulkan.1.dylib [duplicate]

I am trying to run a Swift app on my iPhone 4s. It works fine on the simulator, and my friend can successfully run it on his iPhone 4s. I have iOS 8 and the official release of Xcode 6.
I have tried
Restarting Xcode, iPhone, computer
Cleaning & rebuilding
Revoking and creating new certificate/provision profile
Runpath Search Paths is $(inherited) #executable_path/Frameworks
Embedded Content Contains Swift Code is 'Yes'
Code Signing Identity is developer
Below is the error in entirety
dyld: Library not loaded: #rpath/libswiftCore.dylib
Referenced from: /private/var/mobile/Containers/Bundle/Application/LONGSERIALNUMBER/AppName.app/AppName
Reason: no suitable image found. Did find:
/private/var/mobile/Containers/Bundle/Application/LONGSERIALNUMBER/AppName.app/Frameworks/libswiftCore.dylib: mmap() error 1 at
address=0x008A1000, size=0x001A4000 segment=__TEXT in Segment::map() mapping
/private/var/mobile/Containers/Bundle/Application/LONGSERIALNUMBER/APPLICATION_NAME/Frameworks/libswiftCore.dylib
For me none of the previous solutions worked. We discovered that there is an "Always Embed Swift Standard Libraries" flag in the Build Settings that needs to be set to YES. It was NO by default!
Build Settings > Always Embed Swift Standard Libraries
After setting this, clean the project before building again.
For keen readers some explanation
The most important part is:
set the Embedded Content Contains Swift Code (EMBEDDED_CONTENT_CONTAINS_SWIFT) build setting to YES in your app as shown in Figure 2. This build setting, which specifies whether a target's product has embedded content with Swift code, tells Xcode to embed Swift standard libraries in your app when set to YES.
The flag was formerly called Embedded Content Contains Swift Code
Surprisingly enough, all i did was "Clean" my project (shift+cmd+K) and it worked. Did seem to be related to the certificate though.
I started getting this error when I removed:
#executable_path/Frameworks
from Runpath Search Paths in my build settings. Replacing it fixed everything up again (thank goodness for source control!)
I don't know how it got there, but it appears to be needed for a binary to find its embedded Swift runtime.
For the device, you also need to add the dynamic framework to the Embedded binaries section in the General tab of the project.
In Xcode 8 the option for Embedded Content Contains Swift Code option is no longer available.
It has been renamed to "Always Embed Swift Standard Libraries = YES"
Xcode 13 here (13.1 with react-native).
Created a clean react-native project and saw /usr/lib/swift as an entry in Runpath Search Paths.
After adding that, my project finally ran without crashing!
Nothing helped from what was suggested before.
I think it's a bug when certificates are generated directly from Xcode. To resolve (at least in Xcode 6.1 / 6A1052d):
go to the Apple Developer website where certificates are managed: https://developer.apple.com/account/ios/certificate/certificateList.action
select your certificate(s) (which should show "Managed by Xcode" under "Status") and "Revoke" it
follow instructions here to manually generate a new certificate: https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html#//apple_ref/doc/uid/TP40012582-CH31-SW32
go to Xcode > Preferences > Accounts > [your Apple ID] > double-click your team name > hit refresh button to update certificates and provisioning profiles
I was having this issue with running my Swift tests (but not my app). It turns out that the test needed to have more than #executable_path/Frameworks in it's Runpath Search Paths build setting for the test target. Setting the Runpath Search Paths to the following worked a charm for me:
$(inherited)
#executable_path/Frameworks
#loader_path/Frameworks
OK, sharing here another cause of this error. It took me a few hours to sort this out.
In my case the trust policy of my certificate in Keychain Access was Always Trust, changing it back to defaults solved the problem.
In order to open the certificate settings window double click the certificate in the Keychain Access list of certificates.
This issue occurs again in Xcode 10.2. You must download and install the following package from Apple. It provides Swift 5 Runtime Support for Command Line Tools.
https://support.apple.com/kb/DL1998?locale=en_US
You have to set the Runpath Search Paths to #executable_path/Frameworks as showed in the following screenshot of Build Settings:
If you have any embedded frameworks made in Swift, than you can set to YES the Build Options Embedded Content Contains Swift Code.
I think Apple has already summarized it under Swift app crashes when trying to reference Swift library libswiftCore.dylib
Cited from Technical Q&A QA1886:
Swift app crashes when trying to reference Swift library
libswiftCore.dylib.
Q: What can I do about the libswiftCore.dylib loading error in my
device's console that happens when I try to run my Swift language app?
A: To correct this problem, you will need to sign your app using code
signing certificates with the Subject Organizational Unit (OU) set to
your Team ID. All Enterprise and standard iOS developer certificates
that are created after iOS 8 was released have the new Team ID field
in the proper place to allow Swift language apps to run.
Usually this error appears in the device's console log with a message
similar to one of the following:
[....] [deny-mmap] mapped file has no team identifier and is not a platform binary:
/private/var/mobile/Containers/Bundle/Application/5D8FB2F7-1083-4564-94B2-0CB7DC75C9D1/YourAppNameHere.app/Frameworks/libswiftCore.dylib
Dyld Error Message:
Library not loaded: #rpath/libswiftCore.dylib
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000120021088
Triggered by Thread: 0
Referenced from: /private/var/mobile/Containers/Bundle/Application/C3DCD586-2A40-4C7C-AA2B-64EDAE8339E2/TestApp.app/TestApp
Reason: no suitable image found. Did find:
/private/var/mobile/Containers/Bundle/Application/C3DCD586-2A40-4C7C-AA2B-64EDAE8339E2/TestApp.app/Frameworks/libswiftCore.dylib: mmap() error 1 at address=0x1001D8000, size=0x00194000 segment=__TEXT in Segment::map() mapping /private/var/mobile/Containers/Bundle/Application/C3DCD586-2A40-4C7C-AA2B-64EDAE8339E2/TestApp.app/Frameworks/libswiftCore.dylib
Dyld Version: 353.5
The new certificates are needed when building an archive and packaging
your app. Even if you have one of the new certificates, just resigning
an existing swift app archive won’t work. If it was built with a
pre-iOS 8 certificate, you will need to build another archive.
Important: Please use caution if you need to revoke and setup up a new
Enterprise Distribution certificate. If you are an in-house Enterprise
developer you will need to be careful that you do not revoke a
distribution certificate that was used to sign an app any one of your
Enterprise employees is still using as any apps that were signed with
that enterprise distribution certificate will stop working
immediately. The above only applies to Enterprise Distribution
certificates. Development certs are safe to revoke for
enterprise/standard iOS developers.
As the AirSign guys state the problem roots from the missing OU attribute in the subject field of the In-House certificate.
Subject: UID=269J2W3P2L, CN=iPhone Distribution: Company Name, OU=269J2W3P2L, O=Company Name, C=FR
I have an enterprise development certificate, creating a new one solved the issue.
Let's project P is importing custom library L, then you must add L into
P -> Build Phases -> Embed Frameworks -> +. That works for me.
This error message can also be caused when upgrading Xcode (and subsequently to a new version of Swift) and your project uses a framework built/compiled with an older/previous version of Swift.
In this case rebuilding the framework and re-adding it will fix the problem.
The most easy and easy to ignored way : clean and rebuild.
This solved the issue after tried the answers above and did not worked.
I was having the same problem after moving to a new mac, and after hours, trying all the suggested answers in the questions, none of this worked for me.
The solution for me was installing this missing certificate.
http://developer.apple.com/certificationauthority/AppleWWDRCA.cer
Found the answer here.
https://stackoverflow.com/a/14495100/976628
Change Copy Pods Resources for the target from:
"${SRCROOT}/Pods/Target Support Files/Pods-Wishlist/Pods-Wishlist-resources.sh"
to:
"${SRCROOT}/Pods/Target Support Files/Pods-Wishlist/Pods-Wishlist-frameworks.sh"
I solved by deleting the derived data and this time it worked correctly. Tried with Xcode 7.3.1GM
After having tried out everything, I finally found out, that the build seems not always include every detail again and again. Maybe for speeding up the process...
In order to ensure WHOLE packaging before running on a device, make a Clean first: Shift-Cmd-K.
Then build with: Cmd-B.
After that run it on your device.
Easy.
Kind regards to all you nice guys in that place!
In my case, it was just the name of my target :
I renamed it like this : MyApp.something and the same issue appeared.
But I saw in the build Settings window, my product module name has been changed like this MyApp-something.
So, I removed the dot in my target name (MyAppSomething) and the issue was gone.
For me, having tried everything with no success, what worked was to remove #executable_path/Frameworks from the Packaging section (don't know how it came to be in there in the first place)
We had a unity project that creates an xcode project that includes libraries that use swift.
We tried each and every reasonable suggestion on this thread.
Nothing worked. Code runs fine on new devices, and crashes on iOS<=12
It seems that swift is so smart, that even if you set it to "ALWAYS_EMBED_SWIFT_LIBRAIES"="YES" it does not include the swift libraries.
What actually solved the problem for us is to include a dummy swift file in the project.
The file must contain calls to dispatch, foundation libraries.
Apparently this hints mighty-xcode to force include the libraries, but this time for real.
Here is the dummy file we added that made it work:
import Dispatch
import Foundation
class ForceSwiftInclusion {
init() {
// Force dispatch library.
DispatchQueue.main.async {
print("something")
}
// Force foundation library.
let uuid = UUID().uuidString
print("\(uuid)")
}
}
For unity, also add project.AddBuildProperty(target, "SWIFT_VERSION", "Swift 5"); to your post processing for creating the xcode project.
What worked for me in Xcode 11 was going to General -> Frameworks, Libraries, and Embedded Content and changing the "Embed" option for the framework in question to "Embed & Sign"
None of the solutions worked for me. Restarting the phone fixed it. Strange but it worked.
none of these solutions seemed to work but when I changed the permission of the world Wide Developer cert to Use System defaults then it worked. I have included the steps and screenshots in the link below
I would encourage you to log the ticket in apple bug report as mentioned here as Apple really should solve this massive error:
https://stackoverflow.com/a/41401354/559760
I had the same issue for Xcode 13+ when I create a release build. Had to waste my time on troubleshooting this issue. Finally I was able to fix the issue with following step.
I added a new entry for Release in Runpath Search Paths in Build Settings -> Linking.
/usr/lib/swift
After adding that, I could run my app without crashing!
Xcode 7.2, iOS 9.2 on one device, 9.0 on other. Both had the error. No idea what changed that caused it, but the solutions above for the WWDR were correct for me. Install that cert and problem solved.
https://forums.developer.apple.com/message/43547
https://forums.developer.apple.com/message/84846
There are lot's of answers there but might be my answer will help some one.
I am having same issue, My app works fine on Simulator but on Device got crashed as I Lunches app and gives error as above. I have tried all answers and solutions . In My Case , My Project I am having multiple targets .I have created duplicate target B from target A. Target B works fine while target A got crashed. I am using different Image assets for each target. After searching and doing google I have found something which might help to someone.
App stop crashing when I change name of Launch images assets for both apps . e.g Target A Launch Image asset name LaunchImage A . Target B Lunch Image asset name LaunchImage B and assigned properly in General Tab of each target . My Apps works fine.
For me building a MacOS command line Swift app that depended on 3rd party Swift libs (e.g. SQLite) none of the above solutions seemed to work. What did work was directly adding the following path to my Runpath Search Paths in the Build Settings:
/Applications/Xcode.app/Contents//Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/
Doing that did give a warning at runtime saying that Xcode had found 2 versions of libswiftCore - which makes sense. Except that not including that line resulted in Xcode not finding any versions of libswiftCore.
Anyway, that'll do for me even if it doesn't seem right - my app is just a utility that I'm not intending to distribute and at least it runs now!
I have multiple version of Xcode installed at the same time. The framework was built with a newer version of Xcode. The app that I tried to compile was with an older version of Xcode. When I cleaned and compiled both the framework and the app with the same version of Xcode then things worked.

VS compiling successfully when obvious errors exist after upgrading to framework 4.6.1

After upgrading my .net web project to use Framework 4.6.1 so that I can take advantage of c#6, I have experienced a problem building projects..
I say I have a 'problem' building, it's more like I don't have a problem building. It IS building successfully when in fact it should be failing! Take a look at the screenshot provided; web.config on the left, obvious syntax errors on the right, and a successful build below.
It builds successfully when I do a build / rebuild or run it in debugging; but does actually fail if I try to perform a publish.
Just to further, I have verified that the file that I am editing resides in the correct directory within App_Code, that I am building the correct project and have reset VS multiple times. I've tried to go through all school boy errors; but I think that as it successfully runs but throws a compilation error at that stage it is something down to the Roslyn compiler?
Also note, this is a freshly created project; All I have done is written some basic classes, upgraded the framework, and added a blank aspx page.
Recreating the solution file fixed this error.
Another cause could be down to the fact that I created the project as a WebApplication instead of a Website, but am unsure why this would cause successful builds with syntax errors.
Regenerating the solution with the project setup as a Website instead of a WebAppplication fixed the issue (although I had to change front-end control attributes 'CodeBehind' to 'CodeFile'; a difference between the two types of project).

error when building newly initialized addon

After I had troubles building/serving an addon I'm working at, I did the usual steps to heal (delete node_modules, npm clean, npm install, ...) with no success.
So finally I'm at the stage where I newly created a fresh addon via ember addon jeff-table to port the 'old' not working repo to there....
Addon-creation was successful:
installing addon
create .bowerrc
....
create .npmignore
Successfully initialized git.
Installed packages for tooling via npm.
Installed browser packages via Bower.
Anyway, again I get the same errors when trying to build the untouched addon:
Cannot read property '0' of undefined
TypeError: Cannot read property '0' of undefined
at EmberAddon.EmberApp._initVendorFiles (C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\lib\broccoli\ember-app.js:317:55)
at EmberAddon.EmberApp [as appConstructor] (C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\lib\broccoli\ember-app.js:94:8)
at new EmberAddon (C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\lib\broccoli\ember-addon.js:38:8)
at module.exports (C:\users\jefff\google drive\www\ember-addons\jeff-table\ember-cli-build.js:6:13)
at Class.module.exports.Task.extend.setupBroccoliBuilder (C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\lib\models\builder.js:55:
19)
at Class.module.exports.Task.extend.init (C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\lib\models\builder.js:89:10)
at new Class (C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\node_modules\core-object\core-object.js:18:12)
at Class.module.exports.Task.extend.run (C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\lib\tasks\serve.js:15:19)
at C:\users\jefff\google drive\www\ember-addons\jeff-table\node_modules\ember-cli\lib\commands\serve.js:64:24
I suspected GDrive to have messed up my node_modules or smth, but on a fresh installation this could not be the case (with GDrive switched of).
I have not touched installation of ember-cli (not that I know of).
Does anybody have an idea of what could be wrong here?
ember-cli: 2.5.0
node: 4.2.2
os: win32 x64
Try setting a lodash dependency in your package.json to a version older than 4.17.0. It's a dependency of ember-cli and was updated last night. I had the same error and stack trace with one of my company's projects this morning, it compiled last night in the CI system but failed this morning with no changes to the project. I compared the downloaded dependencies, and a couple had new versions. The first difference was lodash, so I added the 4.16.6 version to my package.json (the version that worked last night) and my project compiled again.
I'm still a novice when it comes to Node, so there may be a better solution, but this isn't the first time I was able to resolve a compilation break by forcing npm to get an older version of a dependency.
the same issue hit my projects as well.
#Bloomy you are right,
error comes from here
/node_modules/ember-cli/lib/broccoli/ember-app.js:317:55
by short debugging it appear that the issue with accessing a property from an object which isn't exist, because, as I guess, lodash 'avoid deep cloning of ._omit result' https://github.com/lodash/lodash/commit/6c427b7a260183685b16d2624351529cda25ce81 .
If you will put version of lodash in ember-cli to some version which goes before (just for your local version) - you will see it works. Not possible for production yet. Going to open a ticket in ember-cli addon if isn't opened yet :)
I was also facing the same issue and raised the following issue in github
https://github.com/ember-cli/ember-cli/issues/6432
And found out that the recent release of lodash i.e. lodash#4.17.0 has a little bug in it which is breaking things. So till a patch is released, try using lodash#4.16.5, this should solve your problem for now.

Building Django on Visual Studio Online

I'm working on a Django (1.8.6) project and using Visual Studio Online's GIT source control. I am building the application successfully in my local environment and push the changes to the VSO. However, whenever I try to build the application on VSO to be able to benefit from "Continuous Integration" as a next step (will try to deploy Azure), it fails by giving the error below:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Python
Tools\Microsoft.PythonTools.Web.targets (235, 5) The environment 'env
(Python 3.4) (unavailable)' is not available. Check your project
configuration and try again.
Unexpected exit code received from msbuild.exe: 1
My build definition on VSO:
Build Definition Screenshot
Python Version: 3.4.3
VS Version: 2015
Any suggestions regarding to my case is highly appreciated.
This is a known issue for PTVS. MS is still working on it. Refer to this thread for details: https://github.com/Microsoft/PTVS/issues/128
There is a workaround in that thread you may use, I quote it here. The second link is unavailabe now, but the first one still works.
For deployment via PowerShell, I found this, which looks correct
AFAIK.
http://www.kenneth-truyers.net/2014/02/06/deploying-cloud-services-to-azure-with-powershell/
You can also use the Python Azure SDK to deploy, but that's not as
well documented. This is what this test does:
https://github.com/Azure/azure-sdk-for-python/blob/master/tests/test_servicemanagementservice.py#L940
Both of these assume that you are able to create the .cspkg, as that's
the file you have to upload to blob storage.

Trying to switch from Xunit.KRunner to xunit.runner.kre?

Today after updating our projects it seems Xunit.KRunner is no longer available on NuGet. We checked the Microsoft projects and it looks like they are using the xunit.runner.kre package. When trying to install this the xunit.assert assemly is failing to download from Nuget. Any suggestions to get this working? I am guessing that the versions are messed up.
Here are my nuget package locations:
I'm also using the beta2 version of the kre.
There is/was an issue with the new xunit.runner.kre and VS CTP 5. See below discussion:
https://github.com/aspnet/Testing/issues/65
xunit.runner.xre is available only on myget/vnext feed. Include that in the Nuget.config that you should be able to restore the package
By running on the beta2 kre you're then having mismatched dependencies. If you look at the versions of your xunit bits they're all beta3. I'd recommend upping your kre to beta3 to fix your issue (will affect which packages your app pulls in).
Also as a side note I'd recommend ensuring your nuget.org/api/v2/ feed is enabled (in the SS you posted it wasn't). There's currently an issue where it'll occasionally disable itself; has definitely made my life frustrating several times when things don't build :).