I have a Xamarin Forms Project, and I do use ShinyLib.net Package https://github.com/shinyorg/shiny.
I do have some bugs with Shiny, which I would like to track down and Fix.
How can I make my project use the Source Code from Git instead of the Nuget Packages so I can Debug and Make changes and try to fix some bugs? Shiny already is using .Net MUAI, but it is still compatible with Xamarin.
I tried to Download the Shiny Source Code, and in my Project, I use Add Existing Project, but it shows me that is Incompatible, and it fails when compiling :
Shiny.BluetoothLE is not compatible with netstandard2.1.
Can someone please explain the correct way for me to compile using source code instead of Nuget Package?
Related
I know, you should not change the Package ID of a NuGet Package. But I did, because of a big refactoring.
Now I want to know if there is a proper way to define a successor NuGet package.
Old ID in Nuspec: OldLibrary1
New ID in Nuspec/csproj file: Library1
If a user opens the NuGet Package Management window for a Visual Studio Solution and the old package (ID OldLibrary1-1.0.0) is installed, he should see an update/upgrade to package Library1-2.0.0.
Is there a possible way to define this in some way?
By the way I use ProGet as NuGet server.
NuGet recently added deprecation information to it's HTTP protocol, however, as far as I know, only nuget.org has implemented it (it's very new, NuGet 5.3, Visual Studio 16.3). If your private nuget server (Proget) hasn't implemented it yet, you can try contacting the developers and ask them to implement it.
Otherwise the best option I've heard about is to create a new version of your old library, do not include any assemblies in it, just have a NuGet dependency on your new package id.
The issue with this is if your package consumer is using PackageReference, Visual Studio's upgrade experience isn't yet great, because when you release a new version of your new package, people getting it as a transitive dependency of your old package won't be notified about the available upgrade. An option to work around this is to include a MSBuild targets file which displays a build warning on every build, telling them to install the new package and uninstall the old package. People who ignore warnings won't see it, so if you want to be extreme, make it an error instead, but it helps get the message out.
I have 2 projects: A & B that I want to publish as NuGet Packages but I don't know how to develop efficiently in Visual Studio.
Solution 1
Project A
Project B - references Project A as NuGet reference
When I make a change to Project A that is needed in Project B do I have to publish Project A? Is there a way to get the project reference functionality during development? Maybe Project B shouldn't reference Project A via NuGet?
There must be a good way to handle this situation, no? I've reviewed the NuGet docs but I couldn't find anything. There must be docs/blogs/SO posts to read more about this... I'm struggling to come up w/ the right keywords.
You might want to look at this extension: NuGet Reference Switcher for Visual Studio 2017
This allows you to switch between NuGet packages and project references during development.
Check out this blog post: https://markheath.net/post/multiple-nuget-single-repo
Basically, dotnet pack handles this for you automatically. You use regular project references when developing.
There must be a good way to handle this situation, no?
The best solutions is that the project-to-project reference should be recommend when the referenced project is modified frequently, the nuget reference is more appropriate when share the reference project to others or publish it. Just like NuGet Reference Switcher doing.
For some more detailed info, you can check following thread:
nuget packages in local work
NuGet has many advantages as a package manager for the Microsoft
development platform, this does not mean that it is not flawed. Just
as you encountered, if the referenced project is modified frequently,
we have to rebuild it, build nuget, publish it for each modification.
That will bring a lot of boring work. To resolve this disadvantages,
the Project-to-project references should be a better way.
The
advantage of a project-to-project reference is that it creates a
dependency between the projects in the build system. The dependent
project will be built if it has changed since the last time the
referencing project was built. A file reference does not create a
build dependency, so it is possible to build the referencing project
without building the dependent project.
You could add following Post-build event command to pack your project after building.
"the nuget.exe path\nuget.exe" pack "project path\NuGetPackageLibrary.csproj" -OutputDirectory "Your target path"
When your build successful, the package in target path will be replaced by the latest version.
I'm using the very latest ServiceFabric SDK (v1.4.87.9494) with VS2015 Update1 and the latest ASP.NET 5 RC1 update (v1.0.11125.0).
When I add an ASP.NET 5 WebApp to my ServiceFabric solution I am seeing an error in project.json that looks like this:
Unable to locate Dependency Microsoft.AspNet.Server.WebListener >=
1.0.0-rc1-final
I'm a super noob to ServiceFabric and ASP.NET 5, how do I go about debugging this?
This is a known (intermittent) issue that will be fixed in an upcoming SDK refresh. In the meantime, you should be able to work around it in one of two ways:
Option 1: In the web project, open project.json, make some kind of cosmetic change (add a space or a newline) and save it. This will force a package restore, which should bring down the WebListener.
Option 2: Explicitly add the WebListener package to the web project. Right-click on the web project, choose Manage NuGet Packages, then search for Microsoft.AspNet.Server.WebListener and install it.
If neither of those work, we've occasionally seen cases where having numerous NuGet package sources exacerbates this problem. You can try de-selecting all sources except nuget.org and that generally fixes it.
Add AspNetVNext to your NuGet package sources pointing to https://www.myget.org/F/aspnetmaster/api/v2/
I have a private NuGet 2.8.5 feed in my internal network, which I use as part of my environment.
I just found that it does not work with some new packages.
Particularly, this package reference the same assembly for two different evironments - DNX 4.5.1 and DNXCore 5.0
That causes following error:
'xunit.runner.dnx' already has a dependency defined for
'Microsoft.Framework.Runtime.Abstractions'.
It looks like NuGet v.2 problem.
NuGet Package Explorer UI tool has exactly the same problem...
So, how can I create a local NuGet v.3 feed, which could serve such packages?
This NuGet.Server package looks abandoned, and I'm not able to find its source code anymore...
A 2.8.6 version of Nuget.Server package got posted yesterday, probably after your post. Perhaps this will fix the problem?
https://www.nuget.org/packages/nuget.server
I thought this problem was fixed. I'm using Visual Studio 2013 and it is Entity Framework 6.1. I get the error message: PublicKeyToken=xxxxxx is not marked as serializable.
I thought this was fixed. Is it broken again and if so, is there a workaround?
Thanks.
Here is the complete error message when trying to install into a win32 C++ console application. (Built with default settings, no other adds to new build.)
Error: Type
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.VCProjectShim' in Assembly
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine, Version=12.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
Here is the complete error message when trying to install into a C++ CLR:
(Actually, it's the exact same error message.)
Here is the complete error message when trying to install into a General Empty C++ Project:
(Again, same error message.)
Okay, I can finally figure out what you are doing. You are trying to run Nuget to download and install the Entity Framework into a C++ project. Yes, that's going to be a fail-whale. Nuget acquired the ability to install C++ libraries at version 2.5, but that only works for native libraries. Pure C++, not managed code like EF. Being a relatively new feature, it doesn't do anything to stop you from getting it wrong, it doesn't filter the available packages to the kind that can work in a C++ project.
The step that fails is the final one, download and copying files work okay but then Nuget runs a Powerscript script to modify the project properties. Which, for EF, was written to work in a C# or VB.NET project. The VS extension model for C++ projects (implemented by the VCProjectEngine class as reported in the error message) is too different to permit that script to complete successfully.
Do keep in mind that the odds of using EF in a native C++ projects are zero. You'll only have a smallish shot at it in a C++/CLI project. Starting with a project template in the CLR node is a required first step.
The next one is to fool the Nuget installer, add a dummy C# project to your solution and run Nuget to get EF installed into that project. You'll see it adding an app.config file to the project, you need to do the same in your C++/CLI project. And it adds two EF assemblies that you also need to add to your C++/CLI project:
Right-click the project in the Solution Explorer window, Properties
Select Common Properties + References
Click the Add New Reference button
Click the Browse button
Navigate to the dummy C# project's packages\EntityFramework.6.1.0\lib\net45 directory
Select EntityFramework.dll you see there
Repeat to add EntityFramework.SqlServer.dll there.
Be sure to write C++/CLI code to use it. Beware that you'll have a Eskimo's chance to find any. The much saner approach is to create a C# library that uses EF and use that library in a C++/CLI project.