I recently ran into a problem upgrading a project I created that was based on the Hot Towel SPA Visual Studio Template. I had a "moment" and accidentally ran the update-package command in the NuGet Package Manager Console, which triggered an update of ALL my NuGet packages - including the Hot Towel NuGet package.
This had the effect of upgrading my project to the latest Hot Towel version and re-adding all the sample views, view models, etc... that I previously deleted or renamed from the original starter project that Hot Towel created. The NuGet upgrade also failed to refresh files that had I had changed intentionally (\scripts\_references.js, \App_Start\BundleConfig.cs) or unintentionally (where VS had normalized tab\whitespace in some files I had opened in the IDE).
Has anyone else experienced this?
It seems pretty unlikely you would ever update the Hot Towel NuGet package for any project that takes root and was built off of the template. I could see later in the project lifecycle updating the dependencies like Breeze, Bootstrap, Toastr, etc..., but just not Hot Towel.
Is it best to just unhook NuGet for Hot Towel once you create your project? This would prevent accidental updates of Hot Towel from re-introducing starter code into your project.
Despite this challenge, Hot Towel is proving to be a great starting point for SPAs. I'm really enjoying working with it.
Thanks,
Richard
Richard - that seems like a good plan if you dont want to re-get the entire package. Hot Towel is a convenience and really intended as a starting point. You want to keep up with it a bit though, perhaps in a new project, to see what new versions are brought down together at times. For example, I am getting ready to release an update to Hot Towel soon with some updates to the libraries. In your case you may want to remove HotTowel's NuGet package, but create a new project. Install the new VSIX (when ready) and see what is different in the dependent libraries.
I'll blog this too :)
Related
I'm building a project as part of a course, I didn't build it from scratch but I've got it at a stable level that compiles perfectly with no errors or warnings.
I need to add Entity Framework Core. The video shows the instructor installing 2.1.4 even though the latest is 3.1.4. What the heck, I install the older version. Everything's still peachy.
But I don't want 2.1.4, I want 3.1.4. I won't go into the reasons, but suffice to say that version supports EDMX. Please don't question me on that. Incidentally I have 3 projects in the solution and only one of them had the EF Core installed. Does that matter? Anyway, after installing 3.1.4 in that one project I get this.
Error NU1107 Version conflict detected for Microsoft.EntityFrameworkCore. Install/reference Microsoft.EntityFrameworkCore 3.1.4 directly to project OdeToFood to resolve this issue.
OdeToFood -> OdeToFood.Data -> Microsoft.EntityFrameworkCore (>= 3.1.4)
OdeToFood -> Microsoft.AspNetCore.App 2.1.1 -> Microsoft.EntityFrameworkCore (>= 2.1.1 && < 2.2.0). OdeToFood D:\Visual Studio Projects\OdeToFood\OdeToFood\OdeToFood.csproj 1
OdeToFOod is the project, OdeToFood.Data is the one of three projects I added EF Core to.
Dear Microsoft, is it asking too much for you to give your error messages in something resembling English? I'm at my wits end with this stupid project. The error message SEEMS to be saying to install 3.1.4 directly to that project. Isn't that what I just did?! Perhaps they mean right-click the project and say manage Nuget for that project instead of "Manage Packages for Solution"? Doesn't make sense to me, but I'll try it. So when I do that it (obviously) already shows 3.1.4 as installed, so that can't be it. So why don't we start nice and fresh, huh? Let's uninstall 3.1.4 from that project and re-install.
Nope. Same error message except this time it mentions a different project, one that never had EF Core installed in the first place. Okay fine Microsoft, I'll play your game. So even though I have no use for it in this second project, I'll install it anyway. Let's see what happens shall we?
OMG.... DISASTER!!!! It's now worse! I still have that error message, but now I have a "package out of dependency constraint" (English please??) and it references ANOTHER package that now has a version conflict, one that hasn't even been touched. What the hell is going on here? I'll bet at this point I can't even go back to Core 2.1.4 anymore. There's got to be some config file or .csproj or something that I can edit because this is unbelievable. I'm trying to follow the directions as best as I can understand them (which isn't much) and it keeps getting worse. And not only that but it appears that EF Core never DID install on this other project anyway so I think there's no fixing this problem at this point, I'm going to have to restore from backup and start over. Why does Microsoft have to make everything so freaking complicated?! Can they at least make this a little more forgiving and user friendly so it doesn't take a PhD to figure out these errors?
I'm just a beginner at this but how am I supposed to learn this if I can't even get a simple thing like this to compile? I try to follow the directions as best I can and that only makes things worse. I'm ready to declare this project FUBAR, throw my computer through a window, buy a sheep farm and never code again!
We love Scott Allen and his tutorials :)
Seems like scoot have updated entity framework with latest version. Link below
GitHub Repository
If you want to update by yourself i suggest to remove ef Core 2.1 packages from odeToFood & OdeToFood.Data project and install ef core 3.1 in both project accordingly. Hopefully this will resolve the issue. Happy learning.
So have created an ASP.NET 4.5.2 project and now need to install react and typescript. I installed node.js so wondering if its best to install via that. Also because I will be using TypeScript I will need the .d.ts files is there an easy way to install these in the project locally? Cause I assume everything else will be installed globally by npm as I might use them in other projects?
One other thing I am confused by all the different types of react packages available on npm, do i need a few or just one of them? I have worked on many projects involving this kind of tech stack but they are established and have never created one from scratch like i am doing now. So some really informative links or tips here would be immensely helpful! :)
So using Visual Studio 2017 I followed this tutorial and managed to get it working. The only issue left now is that i need to call webpack cmd on the project root when i make changes before refreshing the site. I am fine with this and will look into further into automating it as it kind of is a different and unrelated question.
One thing I will include is to always install npm packages globally (most of the time anyway) and just link them in using npm link. Was quite useful considering I went through the process a few times creating the project from scratch over and over again until I understood it all.
About a week ago I noticed strange behavior with my install of Visual Studio 2013 Pro. Creating new projects always results in missing references to EntityFramework and most of the Microsoft.* components. I had reinstalled .NET 4.5 in repair mode around that time but can't recall if this problem happened before or after that install.
As it stands, I can no longer create a functioning project. I have an existing project I'm working on that will compile and run without issue, but creating any new projects (which I need for spike solutions etc) is no longer possible until this is fixed.
Screenshots follow. These are all from creating a new MVC project with all defaults accepted.
References list showing missing references
Error list upon building
Reference paths are empty (this was mentioned in another answer that did not directly address my specific question, so I'm including it)
Regedit showing .NET versions installed
Even though I have "repaired" .NET 4.5 it appears from regedit that I only have up to .NET 4 installed? Am I reading that correctly?
Also, due to network restrictions I cannot download packages from Nuget automatically -- I have to download them manually from a laptop off-network and then sneakernet them over to install. The network physically blocks all connections to Nuget, github, etc.
If allowing VS to connect to Nuget is the only viable option then I have considered installing VS on the laptop, creating the project there and installing all necessary dependencies, and then moving the project folder over to the restricted computer and continuing from there. But I don't know if that is a solution to this problem or not.
Any advice appreciated, thanks.
.
The network blocks all connections to Nuget, github, etc.
It's almost like they don't want you to be productive.
Anyway the project templates (which you seem to be talking about) reference specific NuGet packages. Packages by default are stored relative to your solution.
Place a nuget.config in your disk's root (or any point into your projects directory, if you keep them organized like C:\Dev\Visual Studio\Projects, then each of those subfolders will be file) and point in that file to a shared package directory on your development machine. Here you can dump all packages you require.
There are two command line programs to start/stop/manage your meteor app. There is meteor and there is mrt. As of the latest build (0.8.2 or so) it's really not clear what the difference is between these two, if any. Both seem to support the argument "help" like meteor help and mrt help. The output of both seems to be the same to me.
Sadly, I do not see a "clean" argument available when I check the help for either of these. What do I need to do if I want to achieve a clean build? One that would
Blow away all packages and re-install them
Blow away any compiled templates
Blow away all Sass/Less compiled output
I ask this because I find myself in some kind of dependency Hades right now and want out now.
Meteor is still in a pre-release state. So the idea of packages is (still as of this post) not officially supported, though it will be soon. The meteor community stepped in to build their own way to use 3rd party packages and this is what meteorite does.
Most of the commands you give to meteorite are eventually passed to meteor which is why you see the same output.
The only (main difference is) mrt add which checks atmospherejs.com for packages first.
These two will be merged very soon (there is a branch on meteor on github called packaging which seeks to achieve this)
The idea of 'clean' isn't really there in meteor because most of the stuff is based on hot code reloads, so when a file changes its completely scrapped/(cleaned) and rewritten.
If you change a bit of code it will rebuild all this unless you have a syntax error.
Nonetheless if you want to 'clean' the build from everything you would have to do this in two steps (the meteor part and the meteorite part)
This erases some stuff in the hidden .meteor folder
meteor reset
Delete everything in ~/.meteorite/packages
Delete all symlinks only in your projects /packages folder. Be careful not to delete the folders because these will have been put in by you/whoever made your project and wouldn't be from atmosphere or meteor
Then run mrt update to reinstall all the atmosphere packages from scratch
I wish this is a stupid duplicate of an already answered question.
I have a asp.net website that depends on some other projects (dlls copied to bin). Now, what I want is every time any of those projects are updated, I get latest dlls in my website/bin. I DO NOT want my CI server to check-in updated dlls.
I already have a private NuGet feed for my project, and just want it to serve the latest dlls after each successful CI build. Now, my questions are
Is there a way to directly serve the dlls, without creating nupkg? And probably pick them from build output folder? (for some reasons, it's not that convenient to create package as a post build task for all the dlls hundred times a day) If that is possible, awesome!
If not, can we avoid increasing version number of dlls each time, still make nuget update to the new dlls? Something like update based on latest publish date or something? (there is huge bunch of dlls, and lot of dependencies)
Is there a way to take latest dlls without building the solution? Yeah, I can do a nuget update command, but is there any other way?
Someone suggested mirroring my current code base and using something like MyGet or ProGet. For several reasons, that is not feasible at the moment.
Triggering a Visual Studio build after any NuGet dependencies is probably not quite what you really need - that's a job for CI. However, you can set the version ranges in your packages.config file to make VS (via nuget) pull newer NuGet packages when available.
To answer your specific points:
Why would you want to server 'random' loose DLLs whose origin you cannot be certain of? NuGet provides a mechanism to track the origin of code on which your own code depends, which makes tracking down bugs easier :) If you rely on NuGet packages containing DLLs which change 'hundreds of times a day' then you should likely just build those DLLs directly with your application.
See #1 - if you are re-building NuGet packages very often, then you likely have your package boundaries wrong. Consider how truly independent your packages are, and see if it would makes sense to bring some of the DLLs together, or even separate out (fork) code which is shared between multiple separate applications. If you create a new version of a NuGet package, then you should increase the version number - that's a fundamental premise of semantic versioning, and you'll get into a mess if you do not follow this pattern.
To bring down the latest NuGet dependencies, nuget update is your friend :)
Using MyGet or ProGet might be part of a solution, but it's not directly related to the patterns you mention above.