I am trying to follow Jorge Lusar's suggestion on unit testing Umbraco. I could not get GetRoutingContext method to work because the Umbraco.Web.Routing.UrlProvider constructor is getting a null reference exception (I had downloaded an umbraco 7.0.4 installation previously and compiled the Umbraco.Tests.dll).
As I was getting out of options, I decided to download a fresh copy of Umbraco, compile and run a test that would execute the UrlProvider constructor. To my surprise, I got the null reference exception in there too so apparently, this bug has nothing to do with my solution but Umbraco's instead.
The images speak for themselves. Can anyone plase help with this? Is this really a bug or there's something I can do here?
The solution to the problem was to copy the config settings (the ones in the UnitTests project of the Umbraco solution) to my test project.
Umbraco is dependendant on config files. Not ideal for unit tests but it worked.
Here it is explained how to stub Umbraco dependencies.
Checking over a web.config for a current v7 site I've been working on, the umbracoConfiguration/settings section is of type Umbraco.Core.Configuration.UmbracoSettings.UmbracoSettingsSection.
Another thing you're doing wrong is using as IUmbracoSettingsSection. As means if the cast fails you return a null object, rather than an exception telling you the cast failed - it fails silently. It is better to do:
var umbracoSettings = (IUmbracoSettingsSection)ConfigurationManager.GetSection("umbracoConfiguration/settings");
As mentioned, I think your base type is wrong, and you should actually use:
var umbracoSettings = (Umbraco.Core.Configuration.UmbracoSettings.UmbracoSettingsSection)ConfigurationManager.GetSection("umbracoConfiguration/settings");
This should cast the section into the correct type for you.
Related
I have finally come across something that no one else seemed to have come across (at least from what I can tell). I trying to build an F# type provider using TypeProviders.SDK.
As soon as I build the solution I get the error: "FS0810, Property 'CultureName' cannot be set, \LemonadeProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs" on line 2090 and again at 3162 in the design time project of the solution.
I do not think this is useful but the Test project also fails as it can not find the LemonadeProvider.Runtime.dll. I am assuming this will get created when the Runtime project will build successfully.
PS: As of right now I am just tring to build the provided template, I have not changed the code or added anything to it. Hence I have not attached any code, but please feel free to ask for it.
The corresponding issue is https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/353
Known workarounds
Change minimum target to net461. Replace all instances of net45 with net461, except for in netfx.props, where you can just delete the lines referencing net45* frameworks (I suspect the removal of those lines isn't strictly speaking necessary).
I did this workaround but am now facing these kinds of errors: (like 2000 of them)
C:\Users\user\source\repos\HelloWorldProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs(34,7): error FS0074: The type referenced through 'System.Attribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard'. [C:\Users\user\source\repos\HelloWorldProvider\src\HelloWorldProvider.DesignTime\HelloWorldProvider.DesignTime.fsproj]
I found out that the issue lied with the ProvidedTypes.fs and ProvidedTypes.fsi files created by the SDK.
The issue was solved for me when I replaced the files with the ones found in 'SDK-dsyme-patch-7' which provided compatibility for different .Net environments which was missing from the original SDK. There might be other differences but this is the one I found and it fixed the problem for me.
The files can be found under '/src/' in the dsyme patch.
The code I am referring to is as follows and has been added twice to the ProvidedTypes.fs:
#if NETSTANDARD
asmName.CultureName <- System.Globalization.CultureInfo.InvariantCulture.Name
#else
asmName.CultureInfo <- System.Globalization.CultureInfo.InvariantCulture
#endif
asmName
I am not aware if there is a new SDK that has solved the problem. But at the time when the question was asked, this is what worked for me.
I've been working on a big MVC Application and now i need to improve application's startup performance (which is bad +1min for the first load).
I installed RazorGenerator nugget and the extension too, but when i compile a lot of errors appear.
May this be caused by not specifying the Generator Type?
Because i didn't find their documentation very helpful about this.
Or maybe because i added the following directive to one of my views (_EditHelperPage.cshtml) because it was rendering as HelperPage instead of WebViewPage:
#* Generator: MvcView *#
After i remove this line and adding it to razorgenerator.directives, it throws me another error:
Edit
And if i search for a class/constructor with the same name, it find results in /obj/CodeGen/(...)
I found the problem.
Before i installed the VS Extension RazorGenerator (not the nugget!), i installed RazorGenerator.MsBuild which does the same as the extension but on build time (right?).
But why was it happening?
I think that the extension builds views before MsBuild, however they were doing the same and therefore creating duplicated .cs files
I just unistalled .MsBuild package and voilá, it works.
I've been using Dagger 2 recently and just did some work with scopes in my android project, adding scopes for Activities. While everything runs, builds and tests fine on my own machine. I'm getting a compile error on Jenkins CI.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':Adverts:compile***DebugJava'
.java.lang.ClassCastException: java.lang.String cannot be cast to javax.lang.model.type.TypeMirror
This is strange because the build has worked fine up until now with Dagger 2 just with less code being generated. When I navigate to the generated sources some, but not all of the code is generated. It looks like it's crapping it out somewhere along the way. Both CI and my machine are using the same version of JDK.
Has anybody ran into issues with CI & Dagger 2 before?
For people in the future who encounter this error as well, it's most likely because of a class you deleted or a class that doesn't exist that is being referenced in your Module.
I had the exact same error while compiling when I had code like this:
#Module(includes = {
AModuleThatDoesntExist.class
})
public class YourModule {
}
So what I'm saying is: if you encounter this error, check your Dagger modules and bootstrapper code, there's probably some invalid code there.
As to why it works on your machine and not on the CI server: I don't know. I would guess it's because of some cache issue where the .class file of your deleted .java file is still present on your local filesystem, so Dapper can find it, but it doesn't exist on your CI server. If you can still reproduce the issue, maybe you can try running "Rebuild" and see if the errors occurs locally too.
Whatever happens Dagger 2's annotation processor shouldn't throw an exception so assuming that is coming from the Dagger 2 annotation processor it might be worth raising a bug if you can create a reproducible example, preferably a simple one.
As others have suggested do a clean build (remove the classes yourself to make sure that they are all gone) and check for differences between your machine and the CI one.
i'm working on a project that uses mvc in dotnet. i have to develop the remaining code given to me.I made a copy of the Maincode and tried to run it ;i'm getting this error when i tried to run with breakpoints.
This is the error i'm getting.
i googled and i got a answer saying to refresh the reference i did that too, but its not helping. what can be the problem.
this is the error i'm getting, a screen shot from web.
http://www.google.co.in/imgres?um=1&sa=N&hl=en&biw=1024&bih=621&tbm=isch&tbnid=MuZffsIBSR3nhM:&imgrefurl=https://stackoverflow.com/questions/8506618/no-source-available-error-with-ninject-when-debugging-code&docid=yGGstg8JC99hAM&imgurl=http://i.stack.imgur.com/nlWbT.png&w=1107&h=480&ei=GotmUf2yNYWKrgeam4DYBw&zoom=1&ved=1t:3588,r:3,s:0,i:91&iact=rc&dur=1437&page=1&tbnh=148&tbnw=341&start=0&ndsp=12&tx=91&ty=96
Are you sure your reference to Niniject in web project references is OK? Because it seems like author of the code used sources of ninject (placed in c:\projects\ninject\...) instead of library or nuget package (i dont know why). Try remove that reference and add Ninject as nuget package and see what happens.
Does anyone have know how I can step into system.web.mvc? I am getting an error (Cannot create an abstract class) that is buried in the System.Web.Mvc.DefaultModelBinder.CreateModel method, and I can't tell which part of my code is causing the issue.
I was advised that I could download the sourcecode from codeplex, (actually microsoft.com/downloads as I am using 1.0), build in Debug and then step through. I tried, unfortunately the system.web.mvc was installed in GAC, thus causing an ambiguous call, and gacutil would not allow me to uninstall, so tried by hand removing from the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Global\system.web.mvc). when I ran my program it was still reporting an ambiguous call.
Background
A couple of weeks ago I had a problem where MVC was throwing up a YSOD, but I could not step into the code to find the problem because the issue was I was doing something wrong, that was not being picked up until it was in the framework (in this case, by thrashing around blindly for a day I found it was that I didn't have a default empty constructor on one of the classes within my viewmodel). Now I am getting a different error (Cannot create an abstract class) that is buried in the System.Web.Mvc.DefaultModelBinder.CreateModel method, but I don't know what part of my code is causing the error in the framework.
It's a little involved, but you can do it. Steve Sanderson has step-by-step instructions.
If you have the source code then you can recompile the code using a different assembily name and reference that.