In my SharePoint code, I have the following line:
SPWeb web = site.RootWeb; //site is an SPSite object
When I rebuild my project and run the SPDispose tool on the assembly, I get the following error:
Module: Blah.SharePoint.Features.Core.dll Method:
Blah.SharePoint.Features.Core.Helpers.FeatureDeploymentHelper.RemoveWebPartFiles(Microsoft.SharePoint.SPFeatureReceiverProperties,System.String)
Statement: web := site.{Microsoft.SharePoint.SPSite}get_RootWeb()
Source:
C:\xxx\xxx\Main\Source\SharePoint\Features\Core\Helpers\FeatureDeploymentHelper.cs
Line: 26
Notes: Disposable type not disposed: Microsoft.SharePoint.SPWeb
***This may be a false positive depending on how the type was created or if it is disposed outside the current scope More Information:
http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx#SPDisposeCheckID_140
What I want to do is to have the SPDispose tool ignore this error, so I have pulled the SPDisposeCheckIgnore class and supporting enum into my project, and I've decorated my method appropriately:
[SPDisposeCheckIgnore(SPDisposeCheckID.SPDisposeCheckID_140, "RootWeb does not need disposed.")]
public static void RemoveWebPartFiles(SPFeatureReceiverProperties properties, string assemblyName)
{
...
}
After doing all of this, I still receive the error. Anyone know how I might go about getting rid of that error?
Two things need to be done here.
1) The SPDisposeCheckIgnore class must be defined in the SPDisposeCheck namespace. You CANNOT have your own namespace. See the related comment on this page: http://archive.msdn.microsoft.com/SPDisposeCheck/
2) Anything you are trying to ignore within RunWithElevatedPrivleges must be pulled into an external method or it will not be recognized. This was not being done in the example above, but was being done in other places.
These two rules must be followed for ignore to work. Hope this helps someone else down the road.
Double check how you're retrieving and assigning the RootWeb object. If it's done in an external method, the DisposeChecker might not pick up that it's a RootWeb reference.
I don't see anything wrong with what you've written. I pulled out getting the root web into a static method so I only had to ignore this error in one place, and it works in anonymous delegates. The following worked for me:
public class DisposeUtils
{
[SPDisposeCheckIgnore(SPDisposeCheckID.SPDisposeCheckID_140, "RootWeb does not need disposed. http://blogs.msdn.com/b/rogerla/archive/2009/11/30/sharepoint-2007-2010-do-not-dispose-guidance-spdisposecheck.aspx")]
public static SPWeb GetRootWeb(SPSite site)
{
return site.RootWeb;
}
}
Sorry, I'm not sure if that helps exactly - I'm saying your code should work. Have you checked SPDisposeCheck to see how it handles 'Documented' and 'Undocumented' errors? (I've never been entirely clear what those settings do)
Related
After upgrading to Intershop CM 7.10.18.1, we are getting NullPtr exceptions while opening store detail page in backoffice.
ISML template for store details is EditStore_52.isml, which includes ISCountrySelectBox module, which futhermore calls getCountryNamesAndCodes() method.
That method fails with NullPtr exception because of underlined call which returns null.
We are wondering whether this is a bug and whether the intended code was supposed to be:
countriesMap.put(country.getId(), country.getDisplayName(currentLocale));
Please advise on workaround for this situation.
The following is a stack trace for exception.
Intershop delivers address data which can be imported/export through Operations backoffice (e.g. Login at https://localhost:8443/INTERSHOP/web/WFS/SLDSystem using Organization Operations). Out of the box such address data looks like this:
<country>
<id>DE</id>
<custom-attributes>
<custom-attribute dt:dt="string" name="displayName" xml:lang="de-DE">Deutschland</custom-attribute>
<custom-attribute dt:dt="string" name="displayName" xml:lang="fr-FR">Allemagne</custom-attribute>
<custom-attribute dt:dt="string" name="displayName" xml:lang="en-US">Germany</custom-attribute>
</custom-attributes>
</country>
As you can see, it only contains displayName attribute values for de-DE, fr-FR and en-US. A possible workaround in your case would be to export data, include missing attribute values and import it again.
Please note: The work to deliver a fix for this is already in progress. I'm sorry for the inconvenience.
The more convenient way (because editing xml import files is tedious) would be to replace the erroneous implementation using guice module override. In a nutshell:
Copy paste the original implementation of class com.intershop.component.region.internal.geoobject.LocalizedCountryNamesProviderImpl into a class of your own in your custom cartridge. For example: I just created a class AppSFLocalizedCountryNamesProviderImpl in cartridge app_sf_responsive to test this.
Adapt above method according to your needs
Create an override module (See Cookbook - Dependency Injection and ObjectGraphs). Following my example the modules configure operation should look like this:
#Override
protected void configure()
{
bind(LocalizedCountryNamesProvider.class).to(AppSFLocalizedCountryNamesProviderImpl.class);
bindProvider(com.intershop.component.foundation.capi.localization.LocalizedCountryNamesProvider.class)
.to(AppSFLocalizedCountryNamesProviderImpl.class);
}
Publish your cartridge, Restart your server
I use SpringBoot for REST web services development and SonarQube for static analysis.
I have a few endpoints in my application that look the following way:
#PostMapping
ResponseEntity<?> addSomething(#RequestBody Some object) {
// some code there
return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}
SonarQube complains about using ResponseEntity with a wildcard, reporting me a Critical issue "Generic wildcard types should not be used in return parameters".
I wonder if I should disable this verification in SonarQube or come up with something different for return type for these cases.
What do you think about it?
#PostMapping
ResponseEntity<Object> addSomething(#RequestBody Some object) {
// some code there
return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}
This will also remove the error. It is still very generic, but it is one of the solutions if you want to return different types based on the outcome. For instance:
#PostMapping
ResponseEntity<Object> addSomething(#RequestBody Some object) {
//Will return ResponseEntity<> with errors
ResponseEntity<Object> errors = mapValidationService(bindingResult);
if (!ObjectUtils.isEmpty(errors)) return errors;
// some code there
return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}
So actually i find the rule pretty self describing:
Using a wildcard as a return type implicitly means that the return value should be considered read-only, but without any way to enforce this contract.
Let's take the example of method returning a "List". Is it possible on this list to add a Dog, a Cat, ... we simply don't know. The consumer of a method should not have to deal with such disruptive questions.
https://sonarcloud.io/organizations/default/rules#rule_key=squid%3AS1452
So Actually in your case, you do not want any kind of Class in there, you specifically want an Serializable-object - for obvious reasons: it should be serialized later on
So instead of using ? it would be more suitable in your case to use Serializable. This is always case dependent, but normally you definitly expect some kind of common interface or base class as a return value. Hence that, the follow up developer, definitly knows what he can expect, and what kind of functionality he definitly can use.
Finally I've removed <?> from return value, so the code looks like the following now:
#PostMapping
ResponseEntity addSomething(#RequestBody Some object) {
// some code there
return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}
SonarQube doesn't complain anymore and code seems a little bit simpler now.
I am attempting to migrate from version 3.2.0 to 3.3.0. I am getting a compile error. I could not find an entry in the "Breaking Changes" section but here are my two errors in hope someone can guide me to a workable alternative.
public void RegisterTypeSingleton<T>(Type component, string name)
{
if (_container.Kernel.HasComponent(name))
_container.Kernel.RemoveComponent(name);
_container.Register(Component.For<T>().ImplementedBy(component).Named(name).LifeStyle.Singleton);
}
It seems Kernel.RemoveComponent() function has been depreciated. What has replaced this?
The second compiler error is at _container.Register(Component.For<T>().ImplementedBy(component).Named(name).LifeStyle.Singleton);
I am getting "The Type 'TService' must be a reference type in order to use it as a parameter.
I think you might be upgrading from an older version than 3.2.0. See below.
The removal of IKernel.RemoveComponent() is documented in the Breaking Changes document with v3.0.0. Here is the extract where Krzysztof explains why it was removed:
change - Removed the following methods:
GraphNode.RemoveDepender,
GraphNode.RemoveDependent,
IKernel.RemoveComponent,
IKernelEvents.ComponentUnregistered,
INamingSubSystem.this[Type service],
INamingSubSystem.GetHandler,
INamingSubSystem.GetService2Handler,
INamingSubSystem.GetKey2Handler,
INamingSubSystem.UnRegister(String key),
INamingSubSystem.UnRegister(Type service)
Also INamingSubSystem.Register now takes only IHandler as its argument
impact - low
fixability - none
description - The methods were implementation of "remove component from the container" feature
which was flawed and problematic, hecen was scraped.
fix - Working around is quite dependant on your specific usage. Try utilizing IHandlerSelectors.
For changed Register method, just update your calling code not to pass the name.
handler.ComponentModel.Name is now used as the key, as it was happening in all places so far
anyway, so this change should have no real impact.
RegisterComponent() won't overwrite an existing service registration, it'll just register another component for the same service, unless you specify the same name where it'll throw an exception informing you there is another component registered with that name. If your application doesn't replace components very often you could use the IsDefault() method on the registration to get Windsor to resolve the new component by default, just note the other component is still registered.
If your application replaces components often and you don't want the other registrations left there, you'd be best using a custom IHandlerSelector or ISubDependencyResolver so Windsor will ask you each time what component you want used for a specific service.
Also in v3.0.0 a change was made to ensure that value types cannot be passed to the registration methods. You'll need to add a generic constraint to your method that accepts a generic parameter so that it also only accepts reference types:
public void RegisterTypeSingleton<T>(Type component, string name)
where T : class
{
...
}
Listed below is the definition of my function (vb).
I am trying to check the value of a checkbox inside the function. I am currently unable to do this without getting an error stating that
"Error 305: Cannot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class."
Is there anything I can change so that I can get the value to see that if a checkbox is checked or not? The method must be shared, so it works with the existing javascript and the use of pagemethods
Thanks
<System.Web.Services.WebMethod()> _
Public Shared Function Load(inputs here - taken out for stack overflow) As String
edit- the only other solution i can think of is to find a way for the page's javascript onload to run before the server side, this would solve my issue as well if anyone knows how this can be done.
Yes. Do what the message suggests and make the method non-shared, then you'll be able to access the members of the page.
The 'ASP' namespace seems to be a generated because it's not used in the website project's source code, anywhere (or at least not explicitly used by the programmer of the website). I would like to know how it is fully realized.
For example:
Is it the responsibility of MSBuild to drive creation of the ASP namespace and
if so, where is that instruction found? I
know the C# compiler won't create a namespace from nothing of
its own volition, so the ASP namespace must be fed into it,
even if not used by the website programmer. Maybe it's
generated into the source code by a different tool. The
'Temporary ASP.NET Files' folder might have some bearing on it. As you
can see, I want all the gory details in order to unlock and understand
that namespace ...
Visual Studio seems to have tooling that allows the ASP namespace to be used (IntelliSense support for it) but that masks my understanding of it.
How is the 'ASP' namespace realized in a website from start to finish?
(I haven't found a good article that explains all this.)
Here the ASP namespace is shown in .NET Reflector. (This image taken from Rick Strahl's blog)
The ASP. namespace can be used to Load dynamically a custom control with more safe that the cast will works.
You can control what name the custom control can take in the ASP. namespace by placing the ClassName="ControlClass" on the declaration of the name space and the dynamic control now will have a reference to ASP.ControlClass to make a secure cast when you use the LoadControl
You can read the full steps on MSDN http://msdn.microsoft.com/en-us/library/c0az2h86(v=vs.100).aspx
When you do not use the ASP. namespace and left the control takes an automatic name, then the case may fail (I do not know why, but its fail on my sever time to time) The reference that there created are
namespace ASP
{
[CompilerGlobalScope]
public class Control_Class_nameByDirectory : ControlClass
{
[DebuggerNonUserCode]
public ControlClass();
protected override bool SupportAutoEvents { get; }
[DebuggerNonUserCode]
protected override void FrameworkInitialize();
}
}
And when you try to make a cast like (ControlClass)LoadControl("~/module/Control.ascs") it may fail because is recognize it as Control_Class_nameByDirectory and not as ControlClass
Now if you declare the ClassName on the control header as MSD says, the result is the control to get the same ClassName as the one you have define :
namespace ASP
{
[CompilerGlobalScope]
public class ControlClass : global::ControlClass
{
[DebuggerNonUserCode]
public ControlClass();
protected override bool SupportAutoEvents { get; }
[DebuggerNonUserCode]
protected override void FrameworkInitialize();
}
}
and here you can use the ASP.ControlClass to cast the control with out worry if its fail.
So following the steps that described here http://msdn.microsoft.com/en-us/library/c0az2h86(v=vs.100).aspx you can avoid issues like that. (and that I have face them)
The issue of failing to case a custom control with out reference to ASP. namespace have been seen both on Dot net 4.0 and 4.5 versions. And the worst is that is a random failure - meaning that some times is happens, some time not, and I was unable to find the reason.
I'm going to assume that you're looking for the prefix on server control tags... if that's not the case, let me know.
The prefix is registered in the web.config file under configuration/system.Web/pages/controls. You can modify it if you want, or register additional prefixes for your own control libraries.
MSDN info here: http://msdn.microsoft.com/en-us/library/ms164640.aspx
This namespace is used on the code that ASP.NET generates from parsing your .aspx and .ascx files.
I have no idea why you care, though. It's just a namespace. There's nothing "special" about it, and you shouldn't be referencing anything in that namespace.
To understand how all of this works, read "ASP.NET Life Cycle".