I had a NET45 project published to NuGet. For internal reasons (this is not a production application), I REQUIRE it to be Version 1.0.1 always no matter what. I am using my own private NuGet Server that is currently fully up to date, and TeamCity as my Build Server.
-See TeamCity edit/addition at the bottom-
So after 4 years, I had to make a slight update to this NuGet Package. I did so and Re-Published it as 1.0.1. I do indeed have allowOverrideExistingPackageOnPush set to true, and I am fairly confident the code was overwritten.
Apart from the one tiny code change, I also changed the project to .NET 4.7.2, as well as updating the nuspec From This, To This...
<!-- From this -->
<file src="bin\Release\....dll" target="lib\net45\....dll" />
<!-- To this -->
<file src="bin\Release\....dll" target="lib\net472\....dll" />
When I check on my Server, my nupkg looks like this:
Previously it said net45, but now it says net472. Success?
However, my consuming application (Also not a production app), it its Packages/ folder, Only Includes a ...1.0.1/lib/net45 folder.
I tried every way I could think to wipe, restart, clear-cache, and otherwise obliterate that 1.0.1 package from everything. But still, when I push it, it always ends up with ONLY a net45 folder.
Finally to ease my madness, I allowed my very first ever push of 1.0.2 and, MUCH to my surprise, there was a net472 folder. It was perfect.
So how do I TRULY delete package 1.0.1 and/or alter any lingering records so it isn't stuck as net45?
In TeamCity there is a "Caches" page in the Diagnostics menu. I searched around for the definitions and reasons to Reset some of those caches, but nothing jumped out at me related to this. Also, it says not to touch it unless a TeamCity team member tells you to. Not sure if this is related, but if so, somebody with that expertise would be appreciated.
This was indeed a Caching issue for me. But the cache was a local cache, specifically through Visual Studio, but could also be the NuGet local cache. Though the entire infrastructure was correct, my local machine kept giving me the old version.
In VS, Tools > NuGet Package Manager > Settings > Clear All NuGet Caches.
Related
I have a bog standard .Net Core ASP MVC page utilising EF and utilising Telerik Components.
The project works great on my machine without fail.
I am however no good at the devops side and don't get the ecosystem that goes around the project. I am trying to build a deployable package, and it appears to go through stages where it says "restoring packages for xxxxx"
it then tries to contact https://nuget.telerik.com/nuget/FindPackagesById()?id= for a whole variety of packages and fails
It then goes through "installing" all of them (I can only assume it tries a different repo), then it fails on some one.
The build then fails with
c:\Program Files\dotnet\sdk\2.1.503\Sdks\Microsoft.NET.SDk\targets\Microsoft.PackageDependencyResolution.targets(198,5): Error NETSDK1004 Assets flie xxxxxx not found. Run a NuGet package restore to generate this file.
This file does not exist though and I have tried numerous solutions without any luck (one being to clear the Nuget Cache - and, I waste 2 hours trying to fix the project after that!).
Can anyone advise the next steps?
Maybe what you're experiencing is something similar to this issue which has been reported to Github dotnet /SDK. And the same cause like this issue.
Not sure what the real msbuild command you use in Devops, but please try adding the /Restore or -restore switch to the command. It could look like: msbuild ...... /Restore
Let me know if it helps:)
I have a mobile app app_Old and app_New I have restructured the old into the new, now I want all the packages installed in the app_Old to be installed on app_New. I don't want to manually install it by copying the name and installing nuggets package one after the other. How can I achieve this?
First, I am going to question the wisdom of this proposal. Generally speaking, blindly reinstalling all packages in a new project seems like a great way to replicate / create bloat for libraries you may not be using. NuGet Packages should be installed on an AS NEEDED basis especially for a mobile solution where perhaps space is more restrictive. Often you will be adding libraries which are deployed with your project and cause unnecessary bloat if these are not used. The fact that you have "over 50" on your old project, makes me wonder if there are unneeded packages.
However, there are are a few ways you can do this faster. You could edit your project files manually adding / copying and pasting references and then restoring the packages. The other way is to make a script you can run against the project. You may be able to more quickly do this than point and click re-installing and waiting. Start here for the NuGet Command Line Reference (CLI): https://learn.microsoft.com/en-us/nuget/tools/nuget-exe-cli-reference
Furthermore, keep in mind that just because you have "over 50" nugets installed, doesn't mean you have to install 50. Many of these may get automatically installed as dependencies of other packages.
I've been using this same Sitecore project, for more than 2 years now. Upgraded to Sitecore 7.0 this spring, and everything just ran like it should.
But yesterday, suddenly out of nowhere, i can't seem to run my project anymore. I'm using Visual Studio 2013 with IIS Express (64 bit). And when i try to build and run my site through localhost, it just hangs. I even tried to let it load for 1 hour+, but it still just loads with nothing happening.
I tried to debug it further with Fiddler, but nothing happens. I even tried to delete a bunch of important files, like web.config. But it still just loads forever, with no error.
If i create a new empty web project, i can start it through localhost instantly. So there must be something weird happening with my Sitecore project.
Does anyone have any suggestions for debugging this or have you ever experienced anything like it?
I've nearly tried anything.
I am not sure what version you upgraded from, but I would do the following (in order) to troubleshoot the issue:
Depending on what version you are upgrading from, you may have been running your app pool on .NET Framework v2.0 instead of v4.0, which is required for Sitecore 7. Open up IIS, go to your app pool for the site and make sure that it is correctly set to run on .NET v4.0 and not v2.0. If it was set to v2.0, change it to v4.0 and try access the site. If the issue persists or if the app pool was already running on v4.0 continue to the next step.
As implied in step 1, Sitecore 7 runs on .NET 4.5. If you are upgrading from an earlier version of Sitecore, it is possible that your site is compiled using an earlier version of .NET. Right click on your project files in Visual Studio, click on Properties->Application and make sure that the Target Framework for each of the projects is set to .NET Framework 4.5. If they were set to a different framework, change them, build your solution again, and then try to access your site. If they were already set to target .NET 4.5 or if the issue persists continue to the next step.
Double check the permissions on your site root. Make sure that NETWORK SERVICE and/or your IIS User has all of the necessary read and write permissions for the directory. If they do not, apply the permissions and try the site again. If the problem persists, continue to the next step.
Delete all of the Sitecore DLLs and the DLLs generated by your projects. Copy fresh DLLs from a clean download of Sitecore 7 back into your bin/reference directory and build your solution again. Try to access the site again. If the issue persists, then the problem is likely in temporary internet files or in a config. Continue to the next step if this is the case.
Delete your Temporary ASP.NET Files from the Framework and Framework64 folders found in the C:\Windows\Microsoft.NET directory. Note that you must go into the directory for the version of .NET that your app pool is running against and delete the contents of the Temporary ASP.NET Files directories. It may be necessary to stop your app pool when you do this. Try to access your site again and if the issue persists, move onto the next step.
Try replacing your web.config with the default from a clean download of Sitecore 7, but be sure to back yours up before-hand so that you do not lose customizations, as you will want to add them back in after. Try your site again. This time, you may get an error if something in your code is dependent on the web.config. It is a good thing if this happens, as it means that your site is now working and you have only to add back in your customizations to resolve the errors. If your issue persists, continue to step 7.
If your site is still hanging, try replacing all of your configs in the App_Config directory, one at a time, with their clean copies (excluding ConnectionStrings.config and DataFolder.config, if you are using them). Additionally, disable/backup and remove all custom configs or configs for modules that you have installed that are not Core to Sitecore. Try to access your site again. If necessary, resolve any config errors by merging your changes/re-enabling your configs one at a time until you find one causing the issue or until all errors are resolved.
If your issue continues, post your the Sitecore version you upgraded to, the version you upgraded from, and any modules you have installed as a comment on this post.
I'm using Visual Studio 2010 for two applications, installing to IIS 7.5 on another server. Project A is a web forms web application, and Project B is an MVC 4 web application. During an attempt to set up StateServer between the two applications, I had added a reference to each's .dll in the other's References list. StateServer was abandoned in favor of using a cookie, and the project .dlls were deleted (I did not notice until the installation process that Project B's references were probably also in the list. VS seems to have deleted them from the References when the Project B.dll was deleted, since I did not delete those refs manually).
The problem is, the deployment package is still including them. (I'm just troubleshooting Project A, at the moment.) They are no longer listed in the project's References list, they do not appear in the folder contents under the obj/Release/Package folder, but they DO appear in the installed location after using Deploy -> Import Application in IIS! This includes Project B.dll, as well as many of it's references, such as DotNetOpenAuth.OAuth.dll.
I've run a search through my entire solution on Project A, and have no references to the Project B.dll. I've tried setting up a brand new site in IIS, and deploying to that. I've tried deploying under Staging (QA) and Release configurations, to make sure it wasn't just one of them that was messed up. Under Package/Publish Web, the settings you may be interested in are "Only files needed to run this application", and "Create deployment package as a zip file".
Running the site gives the error, "Could not load file or assembly 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies". This dll is not in the References list of the project, nor the deployment Package folder, nor the installed location's bin folder. It runs with no error, locally.
If I simply remove the extra .dlls manually out of the installed location, I get a compilation error when running the site, complaining a variable is not declared: var lotid = <%=defaultLotID %>; However, this variable is very much declared in the code behind: Public Shared defaultLotID As Integer = 0. And like I said, it runs fine locally. So it seems like a bogus error; just a canary in the mine, maybe.
Seriously, what am I missing? I had no idea how hosed I would be after making a reference to another type of web application. Thank you to whoever takes on the challenge of troubleshooting this one! I'm two days in and coworkers are baffled.
I ended up undoing all my changes, putting my code back to the TFS last check in version. I reintroduced the just the cookie code, built and deployed, I no longer saw the other project's dlls in the installation location. I guess it wasn't going to work to move forward through the reference and subsequent backout. Had to rollback to the prior TFS version, and start over.
How can Update be enabled even though the version number has not changed?
I'm developing a Nuget package. We're in the early stages, beta/testing. We don't change the version until testing is complete but we want to pass on the changed package for testing purposes.
But the Package Manager does not see the change, allow Update, unless the version has changed, I can reinstall but I'd prefer the testers to be able to Update.
How can this be done while the version number stays the same?
Resurrecting this as we are in the same boat (converting a monolithic solution to a Nuget-ified microservices architecture). This method works, though its a bit tedious:
Go to NuGet options and click 'Clear All NuGet Cache(s)'
Do a Nuget package restore on the solution. If this ends up failing due to (e.g. Newtonsoft.json being 'in use by another process') close all instances of Visual Studio & end task on all instances of MSBuild.exe + VBCSCompiler.exe. Restart VS and it should work.
Note that removing and re-adding the package will not work as it will still use the old cached version.
I just faced the same problem and my search brought me to here.
Normally we are using the AssemblyInformationalVersion field to specify prerelease suffixes, e. g.:
0.9.5-beta00001
0.9.5-beta00002
...
When enabling prerelease versions in the NuGet package manager, these packages are offered as well. As long as the suffix expression "increases", the package manager treats subsequent prerelease versions as update. It's important therefore to start with a well-thought suffix, as e. g. the following will not work: beta9 > beta10 (beta9 is treated higher, as the fifth character is higher).
As soon as the suffix is removed, the package is treated as release and is offered as update to all prerelease packages of the same version.
But as life gambles with us, sometimes we identify a small bug or improvement in a just released library. It's always really annoying to increase the version number again for such a microchange, if the just released library even wasn't used anywhere, cause its release is minutes ago only.
For this case I tried the procedure outlined by Simon Storr, but it wasn't enough. I encountered the old version in the packages directory of our solution. After manually deleting it from there, it took the current package from somewhere.
I am not sure if it downloaded the current package at this step, or took it from a more global packages directory that is located in the parent directory of the solution.
Note that there are multiple packages directories!
The properties of the NuGet package in the Visual Studio references view of the project displayed the global packages directory only. But there was the new version already (checked this with ILSpy), while still the old version was copied to the bin directory.