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.
Related
I am new to Asp.Net MVC, trying to create my first website.
I was using bootstrap v4.1.1 in my project until I noticed that a library I wanted to use doesn't support it.
So I uninstalled the package (in Package Manager Console) - and installed the new targeted version v3.3.0.
Made sure that my "\scripts\bootstrap.js" is v3.3.0.
Ran the application, view source, and... surprisingly it was still using v4.1.1!
Double checked the physical files in my solution folder and there is no other "bootstrap.js" flying around!
I then renamed the file to "bootstrap3.js" (and updated the "BundleConfig.cs" accordingly), and it worked!
But as soon as I revert the file name to the original "bootstrap.js", my website starts using v4.1.1 and I have no idea where the system is getting this file from!!!
This is too weird... Hoping someone here has an idea of what's happening.
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
I have always used the express versions of Visual Studio for my Asp.Net projects. In the past, I would use a basic FTP synchronizer to push updated files (*.vb) to our server, then the changes would just show up on the website instantly. Now, for some reason, when I make changes to our *.vb files, they are not being reflected on the server after I synchronize over ftp, unless I build the project first. In addition, for our .Net 4.0 project, VS 2015 14.0.23107 is adding the following directories, with tons of stuff inside of them:
/.vs
/My Project
/Obj
There are loads of files within these directories which I have no idea what they do, and for some reason our project has taken on a completely different behavior. Now when we try to synchronize over FTP, there are a ton more files, and it seems that changing the actual underlying source doesn't work. We have to synchronize all the other files in the above directories, then we can see the changes.
Is this a new way they are doing things, or is this because VS is now free and we are getting a better version where we have to "publish" not "synchronize?"
Is there a way to go back to the simple way of doing things, where we just have a plain directory with our source files and sync them over to the server? Should we not do it this way? If not, what method should we be using and what files should we be pushing to the server?
I'll just promote my comment to an answer. There are several aspects of this question:
Use publish, this feature is already for long available in Visual Studio and works well. There is plenty of ways to customize it and it supports a lot of technologies, including FTP. It's also more convenient, systematic and reliable way of deployment than manually copying files to your FTP. You can also share your publishing configuration among developers and store several of them. No loss here.
I don't quite get why would you like to copy the source (.vb) files to the server. What you would usually like to achieve is to get compiled DLL's + resources copied to your server, and source files 'secure' on developers machines. You can compile your sources on the server if you really need it, but then just plug it into a source control, use ms build etc. Anyway, build/publish actions are there to prepare the deployment files for you, manual copying is pure bad.
For the new folders:
Obj is everything but new, its created to store some resources, crap, more here: What is obj folder generated for?
.vs stores user specific settings, and you should ignore it as well as obj folder, more here:
Should I add the Visual Studio 2015 .vs folder to source control?
My Project is most likely your own folder, nothing related to VS.
To sum up, as long as you use asp 4, 4.5 nothing changes. Only the 5.0 intruduces a bit different rules for deployment. Most of the problems you get are easily solved using the right tools (Publish). It will know what files to ship (binaries + resources included in project) and what to ignore (source files, caches, crap). It's convenient, less error-prone and can do much more for you.
Definitely, use "Publish" option (right click on your web application at solution explorer, under Run/Build options), thus you can update your server site with those files created on Publish. As Mikus mentioned, you DON'T need vb files on your published site, you just need dll's and resources (images, js, css, resx, e.g.).
Regards, hope it helps.
Use the Publish Option which is provided by Visual Studio.
This will compile your project and you can then host this in your reliant manner.
I personally host on IIS and considering I have no data stored locally I can publish directly to the published path on the IIS Server.
The Publish tool is very simple and only takes a few minutes.
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.
Background: Trying to set up my dev. environment in new job. Have subversion installed ok in Flash Builder 4, and checked out the project folders I will be working on. Work to date was developed in FB3, I'm going to be using FB4.
The folders/files that get imported to the project also include .flexProperties, .actionScriptProperties, .project, html-template etc (basically everything).
I would have thought that just the src, libs, lib-rsl etc should be part of the svn?
UPDATE:
Here is a good link to setup details for sharing svn flex projects using 2 folders, one of which has the checkout code, the other of which has folders linked to the first (but without the project/setup files)
It depends on the the development group. If everyone is provided the exact same set of tools in the exact same environments it can be ok to include the IDE project files. But if there is any chance that anyone is going to use a different environment (this includes a rolling upgrade of tools) then it is a bad idea. I recommend against putting these files in source control.