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.
Related
Could I remove the folder C:\Program Files\dotnet\sdk\NuGetFallbackFolder\ or move it to other folder? (better not in disk C)
If could remove, how to remove? delete the folder directly? any side effects or damages?
If could move, how to move? target folder like D:\NuGetFallbackFolder? How can I do it?
This folder contains a set of Nuget packages that the SDK expects to use. It's used as a nuget source whenever dotnet is trying to resolve nuget packages. Removing is generally similar to removing your nuget cache: .NET Core will simply not find the packages and download them into the (normal, non-NuGetFallbackFolder) local nuget cache.
Some distributions of .NET Core do not contain the NuGetFallbackFolder. The only consequence is that dotnet will download all those packages as soon as it needs them (possibly on the first SDK command).
If you move it around, .NET Core won't know about the new location and just treat it as if you had deleted the directory. On Linux, I would use a symlink to point from the old location to the new one. I don't know if Windows supports that.
after searching the internet and trying some in vain:
deleting the NuGetFallbackFolder in the corresponding .NET SDK and
repairing in Windows Uninstall Programm helps really
in my case it worked : the build process in solution got all new in
So this is my problem:
I currently have an existing Umbraco Website, v7.2.1, not installed with Visual Studio, so there is no solution file.
I want to migrate this site to the typical Umbraco solution, so I can run it locally, and make it more familiar to my way of working with Umbraco.
I have tried to create an .NET project and installed the Umbraco Core nugget (also version 7.2.1) followed by importing the website. With no avail.
I rather not move everything manually into a new Umbraco solution.
Help me Umbraco community, you're my only hope.
It depends on how much customization has been done, I think?
I would probably install UmbracoCms -version 7.2.1 (not "just" Core) from Nuget into a fresh solution, build it and then point the connection string to the existing database (if not an .sdf file already). Then you'll (hopefully) only have to copy over folders like /Views and /config plus whatever scripts/styles folder you have, I think? Once copied over, all you have to do is include the folders in your project, and voila.
Unless that too is too much "manual" work? ;-) I'm not sure if you could get by with creating a package on the original site (with templates, doctypes, content, styles, scripts and everything) and importing it into a new, blank site :-s
Again, if you have installed any packages either via Umbraco Package Repository or Nuget, or indeed if you have made changes to /umbraco or /umbraco_client, I don't see any other way to do it other than manually copying them over.
Try doing a, complete, fresh install of Umbraco 7.2.1, then literally copy all the files from the current site, and simply paste and replace them into the new Umbraco solution. That should work.
This is indeed "manual work", but you can literally move all files at once and just overwrite the existing ones in the newly created solution.
Good luck.
Like Jannik said, it depends how much you've build around your current solution and what exact results you're expecting.
Option 1 - WebSite project
You can easily create an empty solution in VS and add new Web Site project (ASP.NET Empty Web Site). Then, paste and include all the files from your current location. You'll have new solution and VS project with your files / website.
Option 2 - ASP.NET Application
If you would like to have it as a ASP.NET app, I would follow these steps (almost the same as Jannik's steps described above):
Create empty ASP.NET Web Application in Visual Studio.
Nuget: Install package -UmbracoCms -version 7.2.1
Repoint connection string to current site database (or replace SDF database file in App_Data directory if it was on SQL CE).
Analyze what packages you've used and try to also install them from Nuget (if they have Nuget packages). If not - move them manually (DLLs etc.).
Copy all static files from your current site (App_Plugins, Configs, Views, Partials, MacroScripts, Scripts, CSS etc.).
But I see also the 3rd option, which may interest you especially if you want to kill two birds with one stone and update Umbraco to the latest version at the same time.
Install uSync and uSync Content Edition on your current website. Perform Full Export. Read more: https://our.umbraco.org/projects/developer-tools/usync/.
Create empty ASP.NET Web Application in Visual Studio.
Nuget: Install package -UmbracoCms
Install uSync and uSync Content Edition on your new web app.
Install all packages used in the previous version.
Copy files from uSync folder in old website and place them into the new one. Perform Import / Full Import.
About: I have a ASP.NET website (not Web project) with 3 class library projects in the solution. Earlier I was using SVN but now Git is used source management. I have installed the git locally on a computer (used as server) and using it for merging the source code from other developers. Also, I am using Visual studio 2015 community edition which provides the tools to work with git.
Problem: After cloning the project from the master repository, I build the project to run it. Building the project shows a dialog box saying "Package Restore is in progress". This process creates a folder named "Packages" and that folder includes every package listed in the packages.config file. But after restoration completes, the project throws the following exception:
This exception shows for each package (Autofac here).
The type or namespace name 'Autofac' could not be found (are you missing a using directive or an assembly reference?)
Work around To Solve this problem, I need to uninstall each package and installed it again and problem is solved. This thing I need to do again and again for each developer machine, which is frustrating and time consuming too.
Does anyone has faced the same problem working with Nuget, git and website in ASP.NET.
I faced a problem like this before. In my case, the reason was that I changed the project path (moved the project to another directory), and the path of the packages directory (that contains the NuGet packages) was stored in the csproj file for the old path, that is VS cannot restore NuGet packages. The solution for this was to edit the csproj manually and make it referring to the correct new packages path.
If this doesn't work for you, you can still use your workaround, but using the following PowerShell command (in NuGet Console) for simplicity:
Update-Package -reinstall -Project Your.Project.Name
Note: project name doesn't contain csproj extension, just the project name
It is good practice to not put third party packages into source control. It bloats your repository (even on a large web application, the size of the external packages will massively out weigh your code).
If NuGet package restore is slow, you could look at using a local cache (this can be as simple as a shared folder) or a better internet connection.
That said, you should only have this problem once per machine. While the packages are downloading you could be giving the new team member an overview of the design…
Make sure that all of your projects are using the same target framework, when this isn't done you can often get the
type or namespace [name] could not be found
warning.
To do this, right click each of the projects in the solution explorer > Properties > Application tab > Target Framework. They should all be the same or there will be incompatibilities between the references in your projects. Here's a question regarding this, hopefully this helps.
The main reason is there no Autofac reference in packages.config file.
When you see on the screen Restore packages message box this mean that nuget package manager is trying to install all the packages which are missing in the package folder.
Try to do this step:
In Visual Studio Solution Explorer pick the project and via context menu pick Unload project
After project was unloaded via context menu pick Edit your project
Go to section group and find you Autofac Reference section
If HintPath doesnt looks like ..\packages\Autofac.4.1.1\lib\net45\Autofac.dll (Actual for 4.1.1 version) remove the Autofac reference Item
Save csproj file and reload project
Install Autofac via NuGet Package manager
Commit and push changes to git repository
Had the same problem with VS 2019. In ASP.NET, packages are updated via the .refresh files that appear in your bin folders. If these aren't checked into Git, they wouldn't be copied down to your cloned repro.
I added the .refresh files for all of my package dlls, made sure the versions and paths in the .refresh files were correct, and now everything updates as expected.
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.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.