I checked out a project form Team Foundation. As you can see in the picture, I used nuget to restore the missing packages. However, the reference problems are not resolved at all.
When I right click on my solution and choose Manage Nuget Packet for Solution, here is what I've got
I thought it means that I have download all the package but they are not added to my project because there are still many build errors. If I use Package Manager Console to download each package separately, the version will conflict with the original. I would like to see if there are any automatic way to resolve this problem.
Thanks in advance
Remember to check out the package folder outside the project folder.
Related
I alter some code in a package at
C:\Users\usr\AppData\Local\.meteor\packages\accounts-ui-unstyled\1.3.0\web.browser\login_buttons.js
The thing is , after I alter the code and run “meteor” in the command line the changes are not implemented, I even deleted the whole package mentioned before and run the app and it was like … nothing happened, it’s like the application have some sort of a cache of the packages that he doesn’t have to go to that path to get them , instead it uses what it had from it before.
Can anyone please explain this to me ? What’s happening here ?
The correct way of "changing" a package is to git clone the package from git (or otherwise retrieve it's source) into either a project internal /packages folder or a project external folder (requires environment variable METOER_PACKAGE_DIRS).
If the package is, as in your case, a Meteor internal package, you can also copy only the package into your project and even add it to your versioning.
In this package you then apply your changes. It will be used in favor of the atmosphere package.
A good practice is to also increment the package version, so it is known for everyone that a custom version is in use.
Why you should not change packages inside the users \Users\...\.meteor installation packages folder?
This is the path to packages, that will be used as defaults for every new meteor project you create. Deep changes can create deep damage to your projects since changing a package will apply to all dependent projects.
Think also about project specific customization. The above described method will allow this, too.
I'm making app with using Xamarin.forms. (PCL Project)
Today, I added new three solution packages named SVG.Forms.Plugin.Abstractions, SVG.Forms.Plugin.iOS, SVG.Forms.Plugin.Android on workspace that downloaded from github.
I have used realm for Xamarin.
But After I added new packages, "Realms.RealmException has been thrown".
Message is "Fody not properly installed. allbX.Baby is a RealmObject but has not been woven."
Is it Fody's problem or Realm's or new packages'(SGV Control)?
And could you let me know how to solve it?
Better Answer
The check which is delivering that message is because Fody is not running.
So, they may have a RealmObject in their component but Fody doesn't get run building in your solution so weaving doesn't occur.
The easiest fix is to just use NuGet to add Fody to your main application project. That should install it in the right place for the solution.
Background
NuGet manages dependencies so if a package relies on Realm, it will go on in turn and install Realm. Realm itself relies on Fody, for example, so will in turn trigger a Fody installation.
You can manually install Realm but it is a little fiddly, having to add a couple of lines to your csproj to specify imports. We have chosen to only document installation via NuGet at this stage.
If you want to manually add Realm to another solution without using NuGet, I suggest you take a new clean solution, save a copy, and diff with the changes made to that solution by adding Realm via NuGet. You will then see the lines to copy into your existing solution.
I'm trying to upload a blob to azure using a shared access signature. I have the token and added the nuget package WindowsAzure.Storage to my project. I've tried both version 7.0.0 and 7.0.1-preview.
For some reason I'm unable to resolve the reference when creating an instance of CloudBlobContainer. Also I've tried to just type the using statement but no luck. All azure documentation points to a version 4.4.0-preview, is this the one I should be using?
azure doc ref https://azure.microsoft.com/da-dk/documentation/articles/storage-xamarin-blob-storage/
Best regards
I would just guess that the docs are outdated with the 4.4.0-preview link instead of a link to the NuGet package:
https://www.nuget.org/packages/WindowsAzure.Storage/
CloudBlobContainer seems to be within the Microsoft.WindowsAzure.Storage.Blob namespace.
I would check to ensure that you actually installed the NuGet package as it may have failed silently with other projects.
EX: http://screencast.com/t/FLhztkeu
Changing the PCL profile worked for me. Bizarre.
After installing the NuGet package, you actually need to change the profile on your Xamarin project. You can do this by going to the shared project -> Options -> General – > C#
Change the Current Profile to PCL 4.5 – Profile111 (I have no idea
of what this does.)
You need to retarget your NuGet packages for this new profile now.
Right click on Packages within the shared project, and you’ll have 5
options here.
Retarget will be available. Click that. (Not shown here, as I’ve
already retargeted)
Rebuild your project
How I figured this out
I stumbled across this Xamarin forum post, where someone had the exact same issue. One user pointed us towards a bug report, where PCL references were not added automatically via NuGet package installation. They recommended retargeting, and it worked! Now I can include the using Microsoft.WindowsAzure.Storage.Blob; namespace.
I have a blog post with more info on this.
I'm facing a problem with connection to the default NuGet source (https://www.nuget.org/api/v2/). It's an issue independent from me and I can't mend it, it's some kind of network related problem.
Does anyone know alternate source(s) I can use?
There's a "..." button in source dialog - can I use some kind of HDD based package source?
If you want to create your own nuget package source. The following article could be useful.
http://docs.nuget.org/create/hosting-your-own-nuget-feeds
I'm using NuGet to create a 'web framework' package containing code, master pages, css, javascript, etc.
In an attempt to speed up the build / test process I'm running nuget.exe update packages.config but I've noticed that it behaves differently than the package manager console's Update-Package command.
nuget.exe update seems to leave the previous version of the package still installed, resulting in multiple versions of the package installed. This usually doesn't cause problems but the Package-Manager Get-Package command shows many versions installed and sometimes the project will fail to build.
Update-Package actually uninstalls the package then reinstalls it, this is cleaner but slower
My questions are:
1. Is there documentation about the difference / relationship between these commands
2. Is the nuget.exe update behavior of installing multiple versions a bug?
3. Is there a better method for creating a package in one project and updating it in another project in a fast & automated manner?
Unfortunately, there's not much official guidelines or documentation except from piecing together forum and work item threads.
Current package manager console behavior was first included as a result from discussion in this thread, which later derived in a work item (sorry, apparently not enough rep to post more links).
However, as others already noted, behavior is not consistent with nuget.exe, where there's no such switch.
So, in answer to your questions:
VS Package Manager Console and nuget.exe do have different behaviors and seem to be updated independently (which is very unfortunate).
nuget.exe update behavior of installing multiple versions side-by-side has been a design feature from the start, as you can find from a comment on David Ebbo's blog about NuGet command line (again, I would have given you the link, but SO still doesn't trust me).
Unfortunately I haven't found anything about using package manager console cmdlets during build. What you could try is manually deleting all folders with your packageId on a build event and then packaging and installing using nuget.exe. Essentially replicate what Update-Package does manually, since as David Ebbo says, the way you uninstall a package through the command line interface is by, well, deleting the folder (again, can't post a reference, this is a bit annoying...)