I've been developing UWP app until I got this error (picture below). I've searched for solution but I couldn't find anything. It doesn't even say which package is the incompatible. How can I find the incompatible package in my solution? Also is there any way to re-create project.json by automatically? I ask it because I changed something on project.json and broke it more.
Also I'm using VS2017 and I'm able to run project without issue. I just can't update package.
Thanks.
(github link for project if you want to look at it.)
I used your GitHub https://github.com/almorax/dota2-handbook-uwp project to troubleshoot the problem and looks like the problem is with the way the nuget package is referred in "Dota2Handbook" project. In other projects, you have used "PackageReference" way to refer the nuget package however in "Dota2Handbook" project you are using project.json to refer nuget package. When I changed "Dota2Handbook" project to use the "PackageReference" way then I was able to get the latest package.
Note: You will notice that "Dota2Handbook.Infrastructure" project already use the new way to refer Nuget packages
More details on PackageReference : https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
What happened to me is that I have UWP projects that were made in VS 2015 and initially targeting Windows 10 RTM. These projects where updated to VS 2017 and to target Creator's Update. All worked fine, and all projects still used the original project.json style.
Then I tried to create a new Windows Runtime Component project and target Creator's Update initially. Targeting Creator's Update in VS 2017 causes the project to use the new PackageReferences project style. This produced the errors shown in the above question when I referenced the WinRT component from the UWP app.
Rather than converting the all of my legacy UWP project files to use the new format, I target the new UWP or WinRT Component library to Anniversary Edition (which uses the older project.json project style), then retarget to Creator's Update.
Of course, at some point updating the project file may be appropriate, just know that it will no longer be supported by VS 2015. Conversion steps are illustrated here.
Related
I have started a project to move some framework libraries targeting Dotnet 4.6.1 to DotnetStandard. I am using VS2017. I started with a relatively simple library which did not have any nuget references and only couple of classes. The approach I took was,
Create a new DotnetStandard 2.0 library project. Just to make sure I have a clean slate instead of manipulating the csproj file of the existing project.
Copy the code files from the old to the new project
Make any code changes required to make the new project build
This worked pretty smoothly. Now, I started with a second library that referenced the first one. I followed the same steps as mentioned above. At Step 3, however, I am hitting roadblock. I am unable to get the namespaces exposed by the first library in the second library, whatever I do. I have tried these,
Referenced the First project from the second project as Project Reference
Created a nuget package for the first project, hosted it in a local folder and installed the package in second project.
Both ways, I am unable to get the namespaces and classes from the first project.
What am I doing wrong?
UPDATE
I tried creating a dummy solution and tried creating two Dotnetstandard projects there. Project referencing worked fine there. So, to experiment, in my actual solution, I deleted the second project and created again. That somehow resolved my issue and I am able to successfully add nuget as well as project references now. Not sure what the problem was earlier.
I'm creating script tasks in SSIS packages using the free BIMLExpress. Since we have different versions of .NET Framework installed in our environment I really need to be able to set the Framework version for the script project. Although I know how to change it manually, it would be very difficult to change it manually.
I have already tried looking for a solution and this answer suggests to use TargetFrameworkVersion property but I don't see that property at all, I've tried using it with no effect. I don't know if it only works with BimlStudio the paid version.
I'm using BIMLExpress 5.0.61915.0 with Visual Studio 2015.
Any help is greatly appreciated.
Thanks
I opened the generated .dtsx package and found that the TargetFrameworkVersion node placed inside of a separate PropertyGroup node. After I had moved it out to the first PropertyGroup of the same arrayElement node, then reopened my package in Visual Studio again, issue was gone! So you can write a script to move TargetFrameworkVersion node into the proper place for now.
Varigence support team told me that a public preview release is coming late next week which will include a fix for that.
I'm having trouble understanding why the Newtonsoft JSON parser has to be device specific under Xamarin. I cannot seem to find any way to have the parser exist in a common, shared library. I'm using the Tasky Pro sample app. I can get the JSON.Net DLLs from the Xamarin store to work in the Android and iOS projects, however that makes no architecural sense. E.g., the SQLite stuff is all in a shared lib, as you'd expect - as one set of c# source files.
Ideally I'd like to just add some kind of reference to "Tasky.Core" and be able to serialize/deserialize JSON.
Is there any way to get JSON.Net to work in a shared library (across droid/ios/wp8)? The source is pretty huge to try to manage as linked files, if that's even possible...
If not, is there some alternative way of managing JSON that will work in this way?
You should be able to use the JSon.NET NuGet Package for this. The implementation is actually platform-specific [1], but NuGet will transparently take care of that for you and pick the correct one for you.
Note that you need Mono 3.2.6 and Xamarin.iOS 7.0.6 for this, which just hit the alpha channel this week, I have just fixed some critical bugs in this area. You should also upgrade the NuGet Add-In in Xamarin Studio to the latest version (0.8), which contains several PCL-related bug fixes.
Simply add the NuGet Add-In to Xamarin Studio if you have not done so already, then search for "JSon.NET", the add-in will automatically install the package and add the required library references for you.
[1] The NuGet package contains different .dll's for different target frameworks and then picks and references the best one for your project - so your application will only contain a single implementation, but an iOS app may use a different one than a desktop application.
Update 01/14/14:
NuGet packages usually contain different implementations - unfortunately, not all of them will work with Xamarin.iOS due to APIs such as Reflection.Emit or Full DLR that are not available on iOS.
If you look into the packages/Newtonsoft.Json.5.0.8/lib/ directory, you'll see different sub-directories - each of these contain a different implementation and NuGet will use the one that best fits the current target framework. Unfortunately, NuGet does not always pick the right one :-(
For Newtonsoft.Json.5.0.8, the "portable-net45+wp80+win8" implementation uses DLR features that are not available on iOS, the "portable-net40+sl4+wp7+win8" one is ok. So if you add the NuGet package to a PCL that's targeting for instance Profile136, you'll get the correct implementation.
There is no GUI to choose another implementation, but you can edit the .csproj file. Replace
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net45+wp80+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
with
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net40+sl4+wp7+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
and it should work.
In general, when you're getting an error message about missing types after adding a new NuGet package, go to the corresponding package directory and grep -r for that symbol - chances are that there's a different implementation which does not use this type.
Hopefully, a more elegant solution will be available in the future, but that needs coordination with the NuGet team and package authors, so it'll take some time.
Just add it to Shared Library via NuGet. Actually, all your request/response tasks should be done in library. You should use JSON.Net to parse response.
I Installed the Nuget Package Installer thing, and it says it installed it.
However I can't find any references to JSON in Visual Studio.
I tried using System.JSON but I can't find it.
How can I use it?
Thanks
I have had been through the same trouble today, when I almost completed my Software Project and just had to use the File to use its contents to change the content of the Project.
For that I wanted to use JsonObject class to get the contents of the .json file. When I tried to write this
using System.Json;
It gave me the exact same error that you might have been going through. It asked for the Assembly files and DLLs.
I kept searching and I stumbled upon to this post, which was totally unhelpfull for me. So I searched and got what I was looking for. After that, I wanted to share that triumph with you people too so that next visitor must have an answer to his trouble on Stack Overflow.
Solution
What I did was, I went to the NuGet website for the System.Json extension package.
http://www.nuget.org/packages/System.Json
There, I capture the command for the installation.
I just click on the Tools --> NuGet package manager --> Package Manager Console and it gave me a new window in the bottom part of Visual Studio 2013.
There I typed (pasted) the link of command I copied. It started and installed the package for me. And now I can use it!
Further answer
I was told that it is a part of .NET v4.5, but I even have the v4.5.1 and still I don't get it why I don't have that package, maybe because on the Web page of the package it is shown deprecated. But still who ever needs it, can have the answer I have posted and it would help him out!
Good luck!
I think you can use the Newtonsoft JSON.NET package.
http://www.nuget.org/packages/newtonsoft.json/
I was also looking for a way to do JSON in C# and saw that they made it easier with .NET 4.5, couldn't do it and found this stack overflow question. I wasn't really satisfied with Afzaal Ahmad Zeeshan's answer so I kept searching and found this which I guess isn't depreciated and worked for me.
Steps in plain English (for .NET 4.5):
1.Add Reference to System.Runtime.Serialization
2.Add "using System.Runtime.Serialization.Json;" to your class
3.call "JsonReaderWriterFactory.CreateJsonReader()" or whatever methods you need to use to read/write json
Install latest VS 2017
Install-Package System.Runtime.Serialization.Json -Version 4.3.0
-- in PM console
I'm using the Crystal Reports Viewer 11 ActiveX control in an Access form (version 2007, 2003 format). Everything works well on my development machine, where I have CRXI installed. I copied the referenced DLL to the client's machine, but when I try to register it, it says "Can't find module" (I double- and triple-checked my spelling) and when I try to open the form it tells me "ActiveX component can't create object" when the code tries to create a new instance of the report object. I suspect there are more dependency files required by the DLL, but I'm a little at a loss as to what ones and how I go about finding out. Although I'm using the CR control, I assume this would apply to any ActiveX control throwing this error. Thanks.
There should be a runtime distribution document in your Crystal Help files - from past experience (Crystal 8.5) there are multiple files that you have to distribute and register.
I'm answering my own question in case someone finds this via a search in the future. I don't have the Access Package & Deploy wizard David mentioned above (okay, I probably have it but couldn't find it readily) but I image it would probably do what I needed, so I recommend anyone try that first. Instead, I was able to create a setup to install tghe needed files using the Visual Studio Installer and the Crystal merge modules; note that while it wasn't difficult, nor was it pleasant.
I downloaded and installed Visual Studio Installer 1.1 from MSDN. This creates a new project type in Visual Studio 6.0 (in particular, I used InterDev 6.0) that creates a Windows Installer (*.msi) setup file. Because one of the Crystal merge modules requires the Crystal license key and VSI doesn't support merge module parameters, I also had to use Orca, a merge module editor, available from the Microsoft Windows SDK (also available on the Microsoft download site). I recommend reading through the SDK and Orca pages on MSDN for more info. Using Orca, I was able to put my key code and recompile the merge module, so I don't have to deploy my key to my users, and my users don't have to enter one.
Again, the Package & Deployment Wizard is probably a better option, but when faced with using merge modules, as with Crystal, this method will get the job done.