I followed a default process to install kentico 13 ASP.NET CORE locally, selected a new site. Then upgraded to 13.0.5. Everything compiled fine and worked as expected. When I tried to deploy the CMSApp project to azure using visual studio, I got this error.
Error Copying file App_Data\Dictionaries\en-GB.dic to
obj\Release\Package\PackageTmp\App_Data\Dictionaries\en-GB.dic failed.
Could not find file 'App_Data\Dictionaries\en-GB.dic'.
Why there are missing dictionaries, I had to pull the missing files from an old Kentico 11 project but, was it something missing during the installation? or could it be a bug?
Is there a way to ignore it?
App_Data-> Dictionaries just had:
en-US.dic
I am pretty sure by default Kentico Xperience only comes with en-US dictionary included.
This is the default culture.
If you need other cultures (like en-GB) then you need to download them from here and include them in your project.
Did you add a reference to App_Data\Dictionaries\en-GB.dic yourself? If you don't need it you could remove it from CMSApp.csproj.
Related
I am publishing my node js site to azure using this tutorial - http://blogs.technet.com/b/sams_blog/archive/2014/11/14/azure-websites-deploy-node-js-website-using-visual-studio.aspx
I get the following error, as mentioned in one of the comments on the blog, any idea what this error is about and how do I fix this ? I am able to run my app locally no issues with that.
Error: InvalidParameter
Parameter name: index
P.s : the site is like a very basic "Hello world" kind of site, this is the first time I am using and deploying to azure too.
I created a new project as a "Blank Azure Node.js web application", and replaced the resulting package.json and .js files with what I had before, and it publishes fine now
All was working fine for and suddenly got the error! I pretty sure it something in the project as it's now happening on vs2013 and vs2015 on different computers.
Its something to do with Templates after a lot of searching. For me Azure TFS CI got things working again if possible for you?
I had this issue with some projects but not with others, all created in a similar way. So I went thought every change and every setting I could until eventually i worked it out. I didn't want to give up and just remake them.
Basically its file paths, the first thing you notice is that it errors very quickly compared to a usual publish, the first thing that is triggered is a build but unlike heavy framework languages there not really much to actually build.
Like all builds for VS it pops out a bin folder take not of where this appears. This is the key, you want this to appear in the root of your deployment usually at the same level as the publish profile.
Before I moved my projects to VS, TFS and Azure, I used to use git and used the azure push and deployment as part of git, so I instinctively structured my folders in the similar fashion with src folder and all the extra VS baggage in the a directory higher.
This is where I noticed bin folder, so re-structured my solution and made changes to .njsproj (notepad) and moved to be inline with source code and re-added it yo my solution.
Technically speaking this a bug within VS as it allows to create the project and specify different locations which is all fine unless you want to build and publish locally.
Once you get your head around what is going on you should be able to solve this problem easily and not make the same mistake in the future. If anyone is still confused comment and ill grab some screen shots.
This is my first azure project and I'm not sure if I'm doing something wrong.
I'm trying to get some configuration inside an MVC 3 webrole and for this I'm using:
RoleEnvironment.GetConfigurationSettingValue(KeyName)
When I run the application on the emulator i get his error:
BC30451: 'RoleEnvironment' is not declared. It may be inaccessible due to its protection level.
I tried to add the full namespace like this:
Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(KeyName)
And I get this error:
BC30456: 'ServiceRuntime' is not a member of 'WindowsAzure'.
However, I can access the RoleEnvironment inside the "OnStart" event of the WebRole class.
So, is it the expected behavior? If yes, how am I supposed to read configuration through the whole project?
Thanks in advance;
Have you added a reference to the Microsoft.WindowsAzure.ServiceRuntime assembly in your MVC project?
http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.aspx
I started a new solution based on seanost suggestion and it worked well, so I figured the problem wasn't VS. After a few try and errors I finally found a solution, I just don't have an explanation for it :-)
Under my MVC project I have a folder called "App_Code".
Since i come from web forms development I'm use to the name so I created this folder to keep some classes. If I try to access "RoleEnviroment" from a class inside this folder the project compiles but won't even open, no matter what I try to access it will throw the same error.
If I rename the folder or move the files to another folder (let's say "Code"), it just works.
As I said before, I just don't know why it happens (and it doesn;t really matter now :-)
FYI, if you're using Visual Studio's Azure templates, references to the following namespaces are included by default, so it's not necessary to set Copy Local to true:
Microsoft.WindowsAzure.Diagnostics
Microsoft.WindowsAzure.ServiceRuntime
Microsoft.WindowsAzure.StorageClient
To make sure Visual Studio and the SDK is installed correctly, you should be able to do the following: Create a new MVC3 Azure project, add a using directive for the ServiceRuntime library in your Home controller, then add the following code in the Index action:
ViewBag.configValue = RoleEnvironment.GetConfigurationSettingValue("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");
return View();
Then, add the following Razor syntax in the View:
<p>#ViewBag.configValue;</p>
And you should get the following result in your browser:
UseDevelopmentStorage=true
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.
I have written a sequential workflow in SharePoint on our development environment. After testing, we decided to deploy this workflow as a feature on the staging environment. We did the following:
copied the strongly named assembly to the GAC using gacutil
copied feature.xml and workflow.xml to WebServerExtensions/12/templates/features/someFolder
installed feature (stsadm command)
activated feature (stsadm command)
All worked exactly as planned and the workflow behaved correctly. The problem was, we decided to change something in the code (a message was not very self explanatory), so on the development machine we updated the message as requested and rebuilt the project.
The problem is, we cannot seem to find a way to correctly get rid of the previous version of this workflow/feature.
To deploy the upgrade, we:
deactivated and uninstalled the feature (stsadm commands), removed also from GAC.
increased the version of the assembly
performed steps 1 to 4 from above.
When using the workflow we are still getting the first message, we cannot find a way to get the new message to be displayed.
What are we missing?
All the workflow logic "lives" inside the code assembly you are running. This means you can delete the old version of DLL (don't change assembly version numbers, use AssemblyFileVersion instead) from the GAC and replace it with the new version.
Be aware, though, that if you have changed the workflow in the designer, running instances of the old workflow version will "freeze" and never finish. Ask your users to finish their running WF-s before you upgrade the code.
It seems that the problem was in the Workflow.xml file.
Because I incremented the AssemblyFileVersion, and only replacing the dll in GAC did not work, I checked the two xml files: Feature and Workflow to see which one did not recognize the new dll (if the case). The workflow.xml file had a reference to the old version in it. I updated that, installed and activated the feature again, and it is working perfectly now.
Thanks for your support!
I just deployed a website into IIS 7 (about which I am woefully ignorant), and upon trying to build the site, I receive this error. I did a little googleing and I saw an article that said I should put system.web.extensions.dll into the /bin. But, I also saw an article saying not to do that. I tried it anyway, but I just received a different error ('Resource cannot be found').
I am totally clueless as to what else to try
Can you use the "Publish" command in Visual Studio to publish directly to the site? If not, then use that command to publish to a similar site on your machine, then copy it to the customer site.
You should also look into the IIS Web Deployment Tool. It can copy an entire site, including IIS settings and any databases. It will be built into VS2010.
Go to control panel, then programs, turn windows features on or off, scroll down to Microsoft.net framework 3.5.1 expand, make sure both sub options are selected, this might help your issue.