Visual Studio 2019 is showing a lot of libraries missing form the Kentico CMS project. I have tried cleaning/rebuilding, and targeting both .NET framework 4.6 and 4.7 without luck. This project was last published more than 6 months ago from Visual Studio 2017 and has been working fine.
When I opened it today and recompiled just to see, it failed. How do I add the missing libraries so it can compile again?
This is what it looks like right now:
If lib folder doesn't have dlls. You can install fresh Kentico without DB to a separate folder and copy dll from there (just make sure it is the same version and hotfix as yours).
Without installing - just download your hotfix (you will find files in the lib folder there as well). You can copy from there.
You may try to switch to nugets. You need 2 mains ones: Kentico.Libraries and Kentico.Libraries.Web.UI (I have version working with nugets).
But honestly would be easier to go the 1st option.
On each file you should be able to see the path of the file. Typically this will be in the Lib folder (at the same level as the CMS) folder. If they’re not in source control that might be the issues. If you know the version of Kentico, you can add the referenced back in with NuGet (search for Kentico.Libraries)
Related
I think I have various beads on why this may be happening, but I can't quite put all the clues together.
We were building an ASP.NET app in VS 2019 with a nuget dependency (Microsoft.Data.SqlClient.SNI.1.0.19235.1 if it matters). I've used msbuild -t:package and in VS 2019, it would spit out bin\x86 and bin\x64 folders with the DLL from that nuget package. That package step would spit out a zip file and opening that up you can see the x86/x64 folders in there.
We upgraded to VS 2022 and the CPU arch folders are no longer there. I can see them get created in the working directory, but not in the package output.
Nothing in the project has changed. It's set to target "AnyCPU" and Framework 4.6.2. The command we're using to build hasn't changed either. As far as I can tell, it's just the upgrade to VS 2022.
I know VS 2022 is now 64-bit native, so I have a suspicion that's in play here. Any ideas on why those CPU-architecture folders are no longer included in the zip package? And how to get them back in there?
Thanks!
According to your description I make some test, hope it can help you:
Check your Configuration Manager under Build in the menu and add new Platform you need.
Build the project in Batch Build under Build in the menu.
We can see that .dll files are created in the same path so it will be covered.
Open the project file.(Right click on the project and Unload Project then right click again an choose edit project file)
You can see code like this:
Change the OutputPath to “bin\x64\Debug\”, ”bin\x64\Release\” and so on.
Reload the project and rebuild the project in Batch Build.
About how to Pack multiple platforms into one package you can see this(Pack multiple platforms into one package, using dotnet pack ).
If it helps anyone, since my problem was specifically with the SNI.dll not being emitted in the x64/x86 folders, my workaround solution was to upgrade the Microsoft.Data.* libraries to a newer version. The x64/x86 folders are still not emitted, but I now see Microsoft.Data.SqlClient.SNI.x64.dll and Microsoft.Data.SqlClient.SNI.x86.dll files in the root bin folder.
It doesn't answer the original question, but at least it got me moving.
We have a library project that we are working on, and in a different project I have the feature branch installed as a Nuget package. Changes are being made on the branch, but version number isn't being updated, so the Nuget package is getting updated, but it has the same name.
I've deleted the Nuget package from my packages folder, so I know I am downloading the latest, and if I manually browse (in the Object Browser) to the dll that I have downloaded to my packages folder, the Object Browser data looks correct.
I've uninstalled and reinstalled the Nuget package in my project, I've turned off all instances of Visual Studio 2017, but still old items are persisting in the Object Browser for my dll that I have installed through Nuget. I am expecting to have build failures because I'm referencing old items, but everything builds successfully, but then when I run the application I am getting run time errors because the old items I am referencing in code no longer exist in the dll that is currently downloaded.
It would be nice if we didn't have to bump version for every build, although we could set up TeamCity to do that automatically, but it would become difficult to maintain all of the extra Nuget packages in our feed.
So, short of just bumping version numbers on the dev Nuget packages, is there any way to clear the cache in Visual Studio 2017 so that the Object Browser updates to reflect the dll that is actually in the packages folder?
I found the problem. In the project where I was testing the library, I had a wpf project and a library project targeting .Net standard. Since the project I was actively working on was wpf I was zoned in on the packages folder in the solution directory, and forgot I was also referencing .Net standards in the same solution which pulls Nuget packages from C:\Users\[username]\.nuget\packages
Because of the project types, Visual Studio had two locations for Nuget packages. One at C:\Users\[username]\.nuget\packages and one at [solution dir]\packages
I updated only the solution directory packages, but apparently Visual Studio 2017 favors the use of the user directory packages, and that is where it was pulling the old API information. After deleting the package from my user directory everything is working as expected.
Here's my setup. I have a classic .Net website, not web app. I have all my compiled objects in a self-hosted nuget repo. When I build in VS, it looks at my packages and copies the binaries to the bin folder but when I try and build in Azure DevOps it's not working. My Nugets restore just fine but I haven't hit on the right msbuild arguments to make it work. I know that .Net websites are not common these days. I found this (How to use NuGet packages with an ASP.NET Website on CI Server) which was a path I was considering (putting .refresh.dll files in source control) but it seems like there should be an easier way.
How do I get my nuget packages copied to bin during a build for a asp.net website (not web app)?
What you are considering (putting .refresh.dll files in source control) is the most appropriate way.
From here:
They are simple because if you view them in a text editor, you’ll see
they contain nothing more than the full path to the dll.
Turns out, these dll.refresh files are an exception to the rule, and
they should go into source control. Its the only way your web project
will know where its references live.
For building and package restore to work, you can keep the bin folder and any .refresh files. You can remove the other binaries from your version control system.
Hope this helps.
In order to use the latest version of resharper on the much-maligend (by me) project I'm currently maintaining, I copied all the source to a separate folder and opened the project in VS 2010.
It converted successfully, so said the conversion report (after informing me it seemed to be under version control but would be unbound since it was missing needed info for that, which I accepted). Yet, although the conversion was nominally successful, in the Solution explorer, beneath the project name, it says "Project Unloaded"
Now for the nitty-gritty: The project has two related solutions, a "regular" (.exe) and a library (.dll) project; they both display in Solution Explorer, but both say "Project Unloaded."
Now for the strange part: When I realized that I had not even copied over the files from the .dll project, I started over and created two separate folders for them (as they have in the development setup), and copied each one's file into each folder.
But now, when I attempt to open the .exe project (the one which had previously claimed it had been converted successfully) from this new location, by selecting File | Open Project and selecting the .sln file, I get, "\.csdproj' cannot be opened because its project type (.csdproj) is not supported by this version of the application.
To open it, please use a version that supports this type of project.*
The dev environment is VS2003 in a XP Mode virtual machine; I'm trying to open the projects now in VS2010 in Windows 7.
Is there a way I can get this project to open and compile in VS2010, so that I can resharperize it (and carry over some of those fixes, albeit manually, one at a time) to the "real live" version of the project?
The best way would be to create a new project in Visual Studio 2010, like you've done. That will create the project folder and any necessary settings.
Next, copy files from your old project to this new folder. As you copy a file into the new folder, also "Drag-N-Drop" that file into your Visual Studio Solution.
The Visual Studio conversion wizard is good from going from the last version to the next version up, but going from VS2003 to VS2010 could be too big of a jump for it.
If I had to guess, this conversion is bombing because your old project targets the .NET Framework 1.0 and VS2010 doesn't do 1.0.
You will likely have to rebuild your project and fix numerous little bugs due to changes in the Framework, but none should be major.
Since there is little information on how to upgrade from Zend Studio 8 to Zend Studio 9, I was wondering if someone had a recommended approach.
My Goal:
To upgrade from Zend Studio 8.0.1 to Zend Studio 9.0
To keep all (or at least most) of my current settings and definitely all of my files
Problems:
I have several projects checked out from SVN
I have more than one workspace
I don't have time to re-checkout from SVN on every project (but if it's the only way then so be it)
Anyway, I just want to know what to watch out for when it comes to bugs or issues with files/settings/workspaces etc.
You should be able to go ahead and install 9.0 without having to worry about loosing your Workspace Preferences. Once the installation is complete. Simply start Zend Studio and specify the same Workspace location(s) you were using before.
If I'm not mistaken workspace information is stored in the .metadata folder created by Zend Studio at the root of your workspace. When you specify your workspace in 9.0 Zend Studio will see this folder and any settings from the workspace while using 8.0 that are still available in 9.0 will still be in place.
As for your projects, if they're not automatically loaded into the workspace in the new version already, simply create a new project, and specify the existing folder of the old project. Zend Studio will see the .project file in the folder and tell you that a project already exists in the specified directory. This is ok, Zend will just attempt to load the old project and retain any project settings for that project.
I'm a bit rusty on the SVN portion. And I have had problems in the past when importing an existing project connected to an SVN Repository. If the Projects repository it is attached to is not already defined in your SVN Repositories view, Zend Studio will start barking at you stating that the project is attached to an unknown repository or something of the sort. If this happens... Well good luck getting it "re-attached" to the repository without just deleting the project and checking it out again entirely.
My advice is to have your SVN repositories setup BEFORE attempting to open any projects that you have connected to a Repo. Make sure to have the configuration all the same when re-setting up your repository definitions.
Good luck! & Gratz on the upgrade. Zend Studio rules.