I inherited an Umbraco 7 VS solution where all Umbraco packages are conveniently added through nuget, along with a dump of the database.
I figured I'd have no trouble getting it to build, but I'm a bit stuck on the Umbraco.Web.PublishedContentModels. This file wasn't included in source control, and was added as a reference for the main web project and another supporting project. In the web.config the ModelsBuilder Modelsmode is set to <add key="Umbraco.ModelsBuilder.ModelsMode" value="Dll" /> .
Obviously if I could open the web project, I could generate the Umbraco.Web.PublishedContentModels assembly, but I can't because the project won't build because of the missing Umbraco.Web.PublishedContentModels assembly.
The model builder VS plugin is also just a frontend for the web interface, so that won't work.
This seems like a Catch-22 situation. Any idea how to proceed?
I have solved this using the following steps:
Downloaded a fresh Umbraco site, exact same version, from Umbraco
Edited the web.config to point to my existing database
Changed the ModelsMode for the ModelsBuilder in the Web.config (<add key="Umbraco.ModelsBuilder.ModelsMode" value="Dll" />)
Copied most of the bin folder of the original site to the new site
This allowed me to generate a Umbraco.Web.PublishedContentModels.dll. It wasn't quite the same, but with some minor changes I could get it to build
Once it builds, regenerate the original Umbraco.Web.PublishedContentModels.dll and undo the changes
In conclusion; don't lose that file.
Related
I did the following steps:
I have created a new Umbraco instance by using the nuget package and visual studio.
I have deployed to Azure, using Azure DB as backend.
Installed the articulate package.
Added my project to version control (including App_Plugins folder, articulate dlls and so on).
I am able delete the umbraco installation and I can restore it completely from version control including Articulate.
Now I am starting to add content, articles, pictures and so on.
Think I do not need to backup the whole folder on the web server. I am doing regular backups of my Azure DB and I need some folders which are also filled with new content, like
media (filling with pictures which I am adding to my articles)
App_Plugins (keeping installed packages in umbraco)
App_Data/packages (file directory for installed packages)
App_Data/umbraco.config (keeping some content for Articulate)
So, is this everything I need to be able to restore the whole system by using the version control part, azure db backup and the listed folders?
Ideally for data/contents you should backup media and App_Data folders. However, if you want to backup Umbraco site (including cache files) then I would recommend App_Plugins, App_Data, Bin, Config, Umbraco & Umbraco_Client folders.
Hope this information helps!
Basically I follow the approach as described in the question. I have added the following files and folders to the Visual Studio project and then later to version control (I have just expanded the more interesting folders which are not part of the project file by default, but needed when you redeploy the solution from scratch):
As described the backend is hosted on Azure SQL.
Open Live Writer makes it very easy to host article content on another ftp server.
By following this approach it is very easy to redeploy the complete solution, e.g. for umbraco upgrades or major changes on the site.
The kpm pack command needs the runtime for the server - is it possible to install windows runtimes on osx just for the pack and deploy?
Ok, it seems that in order to recognise that the deployment is an aspnet vNext project and to handle that as a 'ProjectK Web Application deployment', you have to make it look like it all came from Visual Studio (or at least that was the only way I managed to get it to work right now)...
I did this by taking an example one from somewhere else...
I took a simple single vnext web project .sln file and changed the project name and project GUID.
I took the .kproj Visual Studio project file and did the same.
There isn't much that needs to be changed - only the name of the project and GUID. It's nice that there isn't any file lists in there so I feel that this might end up as a once-only activity...
I did find that there are some project structure rules that seemed to make it break. You seem to have to have the sln file in the top level folder and a folder underneath for the web project. If there is ONLY a web project then this might seem overkill, but I tried collapsing everything up to the top with the sln file correctly pointing, but that didn't work.
The other thing that you need to make sure you have is a reference to "Microsoft.AspNet.Server.IIS" in the project.json dependencies. Without this, the AspNet.Loader.dll and bin folder don't get deployed.
Apart from that, I am now able to use Sublime Text (or whatever I want on osx), test using "k kestrel", checkin through git and it gets deployed automatically to an azure web site! yippee!
Actually this makes much more sense because it is letting the target decide upon the binaries it needs to satisfy the deployments. Next challenge might be to get it to pull 'my' libraries from a custom NuGet source to get my binary libraries in there and avoid uploading ALL of the source to the website!
Oh - and another tip: Quit kestrel with 'Enter' for a clean quit instead of Z which leaves the port listening but non-functional!
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.
We use Team Foundation Server for our main project. Every time we add a new employee either onsite or offsite we always have to set up the references manually.
Is it possible for TFS to copy/save/pass the dll's to the new user without having to install them every time?
For example I add new functionality and install DocumentFormat.OpenXml to my project. Set up the code it runs and works fine on my machine, I publish it works just fine live. I check in everything into TFS.
My co worker downloads the project attempts to build it and it errors out saying it doesn't know what to do with DocumentFormat.OpenXml because no reference exist.
So they they must download DocumentFormat.OpenXml and then they can build and run the project.
Is there a way for TFS to save us this step?
Nothing to do with TFS, really. You just have to check in your dependencies to source control.
In your solution, add a folder called "Dependencies". Add a matching folder on disk in the same location in your solution hierarchy (annoying, I know). Add your dependent external DLLs to that directory.
As these are now part of the solution, they will travel with the solution into source control.
Reference these in your projects. It will look like this
but it should be recorded in your solution file as a relative path.
<Reference Include="Example">
<HintPath>..\..\..\Dependencies\Example.DLL</HintPath>
</Reference>
If you're having problems with this not being the case, you can simply edit your project file and change the hint path.
I have a web application project that I'd like to be able to branch and develop on a totally separate IIS site and not have to keep editing the vbproj IISUrl setting each time I do it. I have tried adding an import of some standard properties so I can maintain them outside of the WAP file but when I reference them in the element it doesn't like them. I suspect it's because the IISUrl element is part of which is a place to put non msbuild info.
As you can see in the code below, I'm trying to reference $(CustomUrl) in a couple spots in the WebApp1.vbproj but when I open VS it's not liking it.
Any way to resolve this or does anyone have a better way to branch off Web Application projects.
CustomImport.vbproj
<Project
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CustomUrl>http://localhost/WebUrl_1</CustomUrl>
</PropertyGroup>
</Project>
WebApp1.vbproj
<Import Project="CustomImport.vbproj"/>
<WebProjectProperties>
<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>1124</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>$(CustomUrl)</IISUrl>
<OverrideIISAppRootUrl>True</OverrideIISAppRootUrl>
<IISAppRootUrl>$(CustomUrl)/</IISAppRootUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>
<CustomServerUrl>$(CustomUrl)</CustomServerUrl>
<SaveServerSettingsInUserFile>False</SaveServerSettingsInUserFile>
</WebProjectProperties>
I believe I might have a workaround for this in VS2010.
Right click on the project in VS2010 and go to Properties. In the Web tab, Uncheck the "Apply server settings to all users (store in project file)". What this does is forces all of the settings to be stored in a [Web Project Name].csproj.user file instead of in the project file itself. (Mine is a C# project instead of VB, but I assume it works the same) This allows you to have different server settings on each machine doing development, but at the same time share the rest of the configuration.
I had to do this because I'm using SSL certificates on each development machine (workstation and laptop) so the Project URL is different, but I don't want to have to manually mess with the URL on each machine more than once and worry about it while checking my code into source control.
Once you've done the initial configuration on a machine after getting the latest source, your .user file holds the configuration. So long as you're not checking .user files into source control this seems to work fine.
I've been plagued by the same problem for several years now. The problem persists all the way from Visual Studio .NET (2003) up until now (VS 2010). I have searched for an automated solution for automatic URL renaming but without any success.
What I've been doing to avoid this problem is branching way more and having lots of different workspaces:
Root branch for ongoing project
-> Branch for dev-team
-> Branch for support and long-term code integrity (this is the most commonly used branch by me)
-> My personal custom branches that have different URLs set
I know it's not the best solution but this is the best one that I could figure out.
This article on programmatically changing a project file may be of some use to you in creating a solution to automate the changing of those settings:
Programmatically change Web project settings from dynamic port to static