Eyeshot is distributed via NuGet packages, which include support for .NET Framework 4.7.2, .NET 6, .NET 7, and .NET 8.
This article aims to provide a detailed guide on handling NuGet packages.
Visual Studio projects can be distinguished between SDK-style projects and Legacy projects.
Since SDK-style projects benefit from a simplified project file format and better dependency management, we suggest using this type.
If you rely on a legacy project, you can refer to this article that explains limitations and considerations to keep in mind, as well as the procedure to upgrade to the new SDK format.
Nuget packages installation
For SDK-style projects, it is possible to use the integrated extension menu in Visual Studio as explained in detail in this article.
In general, you can use the standard procedure to install the packages.
In the Solution Explorer panel, right-click on the References item of the wanted project, then click on Manage NuGet Packages...
This will open the NuGet packages management page for the project: check that the package source is correctly set to Eyeshot 2024 Local (if not, select it from the selection combo box), go to the Browse tab, and then select and install the wanted NuGet package.
You have to install one of the following packages:
- devDept.Eyeshot: install this package for a console application project;
- devDept.Eyeshot.Control.Win: install this package for a Windows Forms application project;
- devDept.Eyeshot.Control.Wpf: install this project for a WPF application project.
If you plan to use the ReadAutodesk or WriteAutodesk classes, you have to also install an additional package:
- devDept.Eyeshot.x64: install this package to manage DWG/DXF files for x64 projects;
- devDept.Eyeshot.x86: install this package to manage DWG/DXF files for x86 projects;
For guidance on configuring and using the devDept NuGet Server, please refer to this article.
Beta and nightly releases
Following NuGet guidelines, to install a beta or nightly release, you must enable the 'Include prerelease' option.
Package source mapping
Following the installation of Eyeshot, a local folder containing the NuGet packages is already mapped.
If you encounter problems while adding the packages, you can verify that the configuration is correct.
The first thing to check is that there exists a package source correctly mapping the local offline location of the Eyeshot NuGet Packages.
In Visual Studio Select the menu Tools>NuGet Package Manager>Package Manager Settings.
In the opened window, select the Package Source item on the left pane, and check that it exists and is enabled a source named Eyeshot 2024 Local pointing to the folder where the Eyeshot NuGet packages have been installed.
If not, create a new source by pressing the Add button (the green cross in the following picture) and name it accordingly.
Beware to have also the nuget.org source correctly configured as shown in the picture below.
Comments
First of all, sorry for cross-posting a related question here http://devdept.zendesk.com/hc/en-us/community/posts/12239219812636/comments/12347057577372 , but I thought it might help others in similar situations.
We're building our application in a CI/CD pipeline on Gitlab at the moment. This change (...This is the only way to install Eyeshot 2024...) seems to imply that we won't be able to build our app anymore unless we somehow manage to get these nuget packages hosted on a location that's accessible by our CI build process...
It would be very nice if there would be a way for us to make use of some kind of public nuget resource to download our packages from, instead of having to rely on locally distributed packages. For example: DevExpress uses a hosted nuget repository that is accessible for any customer with a license by using a private api endpoint based on a unique key. Could this be an option somewhere in the near future?
If not, what would otherwise be the recommended way to do CI builds of applications using the EyeShot component?
Hi Gert,
we're currently working on setting up a private NuGet server, so as soon as it will be ready you shouldn't have any problem with your use case.
We will keep you all updated with an official announcement, as soon as any news is available.
In the meantime, we are deploying Eyeshot as usual with a setup, and the NuGet packages are installed with it.
Hi Frederico,
Thanks for your quick answer. Does "In the meantime" extend into the release window of the 2024 version too?
Hi Gert,
as you can see, now the devDept NuGet server is up and running: you could follow the updated info of this article, in order to set it up and perform the first tests on your side.
Please, feel free to share your feedback: they will be very helpful.
WOW! That was insanely fast! Very impressive :)
First observations:
- The repository currently shows only the 2024.0.73 version, marked as stable. Does this mean it is not in BETA anymore?
- Will I be able to access the current 2023 version on this repository too in the future? (this would make testing easier, because it won't require me to update my app first)
Hi Gert,
Thank you so much for your feedback!
- Starting from the next beta release, the beta packages will be correctly marked as prerelease (we just updated this article too).
- Regarding the 2023 version, currently, there are no plans to publish packages for it. However, we'll reassess this decision after gathering more feedback during the Beta period.
Just downloaded the officially released version of Eyeshot (2024.1.203), but this version does not yet appear to be available on the Nuget Server (https://nuget.devdept.com/nuget).
Can you confirm?
Hi Gert,
actually, now it should be visible; could you please check it again?
However, an official announcement for Eyeshot 2024.1 will follow, that will contain all the official info and communications.
Yes! It works now. Great work. Thanks.
Please sign in to leave a comment.