I've had to upgrade to Visual Studio 2015 and am currently having problems with my VSPackage. I need a VersionContralServer object, but everytime I debug, DTE is null.
DTE2 dte = (DTE2)Package.GetGlobalService(typeof(DTE2));
VersionControlExt versionControlExt = dte.GetObject("Microsoft.VisualStudio.TeamFoundation.VersionControl.VersionControlExt") as VersionControlExt;
VersionControlExplorerExt versionControlExplorerExt = versionControlExt.Explorer;
VersionControlServer version = versionControlExplorerExt.Workspace.VersionControlServer;
Any help appreciated.
You've got a slight bug in your call to Package.GetGlobalService().
DTE2 dte = (DTE2)Package.GetGlobalService(typeof(SDTE));
Under the hood, all the GetGlobalService call is doing is invoking an IOleServiceProvider.QueryService method, and that function requires an interface guid, and a service guid. typeof(DTE2), returns the interface guid for the DTE2 interface.
Some samples you may have seen improperly used typeof(DTE) to return the service guid. But that only works, because the DTE service guid id, and the DTE interface guid id, just happen to be the same thing. But in general, you should always use the service guid id.
Related
I was using Breeze v1.1.2 that came with the Hot Towel template which has now been extended to form my project. I made the mistake of updating the NuGet package to the current 1.3.3 (I never learn). Anyway, all was well, and now not so much!
I followed the instructions in the release notes and other docs to change my BreezeWebApiConfig file to:
[assembly: WebActivator.PreApplicationStartMethod(
typeof(BreezeWebApiConfig), "RegisterBreezePreStart")]
namespace MyApp.App_Start {
public static class BreezeWebApiConfig {
public static void RegisterBreezePreStart() {
GlobalConfiguration.Configuration.Routes.MapHttpRoute(
name: "BreezeApi",
routeTemplate: "breeze/{controller}/{action}"
);}}}
And the config.js file (which provides the serviceName to the EntityManager constructor) to:
var remoteServiceName = 'breeze/breeze'; // NEW version
//var remoteServiceName = 'api/breeze'; // OLD version
And my BreezeController if you're interested:
[BreezeController]
public class BreezeController : ApiController
{
readonly EFContextProvider<MyDbContext> _contextProvider =
new EFContextProvider<MyDbContext>();
[HttpGet]
public string Metadata()
{
return _contextProvider.Metadata();
}
[HttpGet]
public IQueryable<SomeItem> SomeItems()
{
// Do stuff here...
}
}
Now I get the "cannot execute _executeQueryCore until metadataStore is populated" error.
What am I missing here?
EDIT:
I perhaps left out the part you needed... Above in the SomeItems() method, the stuff that actually gets done is a call to the GetMeSomeData() method in the MyDBContext class. This method makes the following call to a stored procedure to get the data.
public virtual ObjectResult<SomeItem> GetMeSomeData(string inParam)
{
var p = new object[] { new SqlParameter("#inParam", inParam) };
var retVal = ((IObjectContextAdapter)this).ObjectContext.ExecuteStoreQuery<SomeItem>("exec GetData #SN", p);
return retVal;
}
Now given my limited understanding, the call to Metadata() is not failing, but I don't think it has any idea what the entity model is when coming back, even though somewhere along the line, it should figure that out from the entity model I do have (i.e. SomeItem)? The return string from Metadata() doesn't have any information about the entity. Is there a way to make it aware? Or am I just completely off in left field playing with the daisies?
Hard to say based on this report. Let's see if Breeze is right.
Open the browser debugging tools and look at the network traffic. Do you see an attempt to get metadata from the server before you get that error? If so, did it succeed? Or 404? Or 500? What was the error?
I'm betting it didn't even try. If it didn't, the usual reason is that you tried some Breeze operation before your first query ... and you didn't ask for metadata explicitly either. Did you try to create an entity? That requires metadata.
The point is, you've got to track down the Breeze operation that precipitates the error. Sure everything should just work. The world should be rainbows and unicorns. When it isn't, we heave a sigh, break out the debugger, and start with the information that the error gave us.
And for the rest of you out there ... upgrading to a new Breeze version is a good thing.
Happy coding everyone.
Follow-up to your update
Breeze doesn't know how you get your data on the back-end. If the query result has a recognizable entity in it, Breeze will cache that. It's still up to you in the query callback to ensure that what you deliver to the caller is something meaningful.
You say that you're server-side metadata method doesn't have any idea what SomeItem is? Then it's not much use to the client. If it returns a null string, Breeze may treat that as "no metadata at all" in which case you should be getting the "cannot execute _executeQueryCore until metadataStore is populated" error message. Btw, did you check the network traffic to determine what your server actually returned in response to the metadata request (or if there was such a request)?
There are many ways to create Metadata on the server. The easiest is to use EF ... at least as a modeling tool at design time. What's in that MyDbContext of yours? Why isn't SomeItem in there?
You also can create metadata on the client if you don't want to generate it from the server. You do have to tell the Breeze client that you've made that choice. Much of this is explained in the documentation "Metadata Format".
I get the feeling that you're kind of winging it. You want to stray from the happy path ... and that's cool. But most of us need to learn to walk before we run.
I have a SaaS application that creates expenses within QuickBooks Online. In the the IPP documentation (https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online/Bill) it shows that on a line object you can specify the AccountID (its the last field in the documentation) and that is required to create an account-based expense.
However, in the .NET object for BillLine, there appears to be no way to specify that data. Does anyone know how to create an "Account-based Bill Expense" using the .NET SDK?
Intuit.Ipp.Data.Qbo.BillLine billLine = new Intuit.Ipp.Data.Qbo.BillLine();
billLine.ItemsElementName = new ItemsChoiceType1[] {ItemsChoiceType1.AccountId, ItemsChoiceType1.AccountName};
billLine.Items = new object[] {new IdType() {idDomain = idDomainEnum.QB, Value = "123"}, "MyAccountName"};
Any properties that are not exposed directly are defined in the ItemsElementName property, and the value is passed in the respective index in the Items object array. You will see this across most entities in the .NET DevKit.
We have a custom built application, based on silverlight, which manages our report subscriptions. The problem is that whenever you add a new subscription, it sets the Locale value in the Subscriptions table to 'en-US'.
When you create subscriptions directly in Report Manager, the value in the Locale field is determined by your browser language settings (this is exactly what we want to achieve).
We can't find a way to set the Locale field before we call the CreateSubscription method as it doesn't seem to accept the Locale parameter and it defaults to en-US (which I believe is a server setting).
Do you know of any way to set Locale when creating subscriptions in SSRS?
As far as I can see there is no way to do this; I've been using the service via C#.
I decided upon a solution of obtaining the language/locale of the report via the service, and then making the changes directly in the ReportServer database, as an UPDATE statement on the SubscriptionID.
To get the language/locale of the report I use something like:
private static void Main()
{
ReportingService2010 service = new ReportingService2010();
service.Url = "URL of service";
service.Credentials = System.Net.CredentialCache.DefaultCredentials;
string reportItemPath = "Path of report";
string language = GetReportPropertyValue(service, reportItemPath, "Language", "en-GB");
// Create the subscription, then update the database using the returned SubscriptionID.
}
private static string GetReportPropertyValue(ReportingService2010 service, string itemPath, string propertyName, string defaultValue)
{
Property[] properties = service.GetProperties(itemPath, null);
if (properties.Any(p => p.Name == propertyName))
return properties.First(p => p.Name == propertyName).Value;
else
return defaultValue;
}
I haven't tried it via the SOAP API yet, but shouldn't it be possible to set the Accept-Language header?
I'm doing this when rendering reports in different languages. The language of each report is set to =User!Language.
When using WCF to access the reporting service, you can do (example as VB.NET)
Using oReportingService As New ReportingService2010SoapClient
oReportingService.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation
Using oScope As OperationContextScope = New OperationContextScope(oReportingService.InnerChannel)
If i_oSubscription.Language IsNot Nothing Then
' Accept-Language
Dim oHttpRequestProperty As New HttpRequestMessageProperty
oHttpRequestProperty.Headers.Add(HttpRequestHeader.AcceptLanguage, i_oSubscription.Language)
OperationContext.Current.OutgoingMessageProperties(HttpRequestMessageProperty.Name) = oHttpRequestProperty
End If
oReportingService.CreateSubscription(New ReportingService2010.TrustedUserHeader(), i_oSubscription.Path, oExtensionSettings, i_oSubscription.Description, "TimedSubscription", sMatchData, lstParameters.ToArray(), sSubscriptionId)
Return sSubscriptionId
End Using
End Using
Edit: This is the way I'm doing it myself and it seems to work :)
i_oSubscription is just a simple container with properties like Description
Note: this seems to work for the most part. However, the "Days" field in a MonthlyRecurrence is to be formatted locale-dependent (see: https://stackoverflow.com/questions/16011008/ssrs-monthlyrecurrence-formatting-for-different-languages)
I'm trying to query QBO for, among other entities, Accounts, and am running into a couple of issues. I'm using the .Net Dev Kit v 2.1.10.0 (I used NuGet to update to the latest version) and when I use the following technique:
Intuit.Ipp.Data.Qbo.AccountQuery cquery = new Intuit.Ipp.Data.Qbo.AccountQuery();
IEnumerable<Intuit.Ipp.Data.Qbo.Account> qboAccounts = cquery.ExecuteQuery<Intuit.Ipp.Data.Qbo.Account>(context);
(i.e. just create a new AccountQuery of the appropriate type and call ExecuteQuery) I get an error. It seems that the request XML is not created properly, I just see one line in the XML file. I then looked at the online docs and tried to emulate the code there:
Intuit.Ipp.Data.Qbo.AccountQuery cquery = new Intuit.Ipp.Data.Qbo.AccountQuery();
cquery.CreateTime = DateTime.Now.Date.AddDays(-20);
cquery.SpecifyOperatorOption(Intuit.Ipp.Data.Qbo.FilterProperty.CreateTime,
Intuit.Ipp.Data.Qbo.FilterOperatorType.AFTER);
cquery.CreateTime = DateTime.Now.Date;
cquery.SpecifyOperatorOption(Intuit.Ipp.Data.Qbo.FilterProperty.CreateTime,
Intuit.Ipp.Data.Qbo.FilterOperatorType.BEFORE);
// Specify a Request validator
Intuit.Ipp.Data.Qbo.AccountQuery cquery = new Intuit.Ipp.Data.Qbo.AccountQuery();
IEnumerable<Intuit.Ipp.Data.Qbo.Account> qboAccounts = cquery.ExecuteQuery<Intuit.Ipp.Data.Qbo.Account>(context);
unfortunately, VS 2010 insists that AccountQuery doesn't contain a definition for SpecifyOperatorOption and there is no extension method by that name. So I'm stuck.
Any ideas how to resolve this would be appreciated.
I am looking for extensions that implement a specific extension point, and am using the following acceptable method to do this:
IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();
if (extensionRegistry == null) {
return TEMPLATES;
}
IConfigurationElement[] config = extensionRegistry.getConfigurationElementsFor("com.ibm.im.launchpoint.templates.template");
I then would like to get the version of the defining bundle. I would use the following API, but the API for PluginVersionIdentifier is deprecated:
for (IConfigurationElement e : config) {
BlueprintTemplate template = new BlueprintTemplate();
IExtension declaringExtension = e.getDeclaringExtension();
PluginVersionIdentifier versionIdentifier = declaringExtension.getDeclaringPluginDescriptor().getVersionIdentifier();
I could not find an alternative in the new API - i.e. from a IConfigurationElement, how do I get the version id descriptor of the bundle. Obviously, from the Bundle I can get the version using the Bundle.getHeaders(), getting the Bundle-Version value - but how do I get the Bundle in the first place??? Platform.getBundle(bundleId) is not enough since I might have multiple versions of same bundle installed, and I need to know who I am. At the moment I have a chicken & egg situation, and the only solution I have is the above deprecated API.
All this information is based on Eclipse 3.6:
Your IContributor will be an instance of RegistryContributor if you are in the osgi environment which of course you are or you wouldn't be having this issue.
RegistryContributor gives you two methods: getID() and getActualID(). getID() may return the host bundle if this was loaded from a fragment. getActualID() always loads the id of the fragment/bundle the contributor represents. You can use this id in your BundleContext.getBundle(long id) method. Here is a snippet:
Bundle bundle;
if (contributor instanceof RegistryContributor) {
long id = Long.parseLong(((RegistryContributor) contributor).getActualId());
Bundle thisBundle = FrameworkUtil.getBundle(getClass());
bundle = thisBundle.getBundleContext().getBundle(id);
} else {
bundle = Platform.getBundle(contributor.getName());
}
I use a fall through method that will degrade gracefully to a non-version aware solution if IContributor gets a new default implementation in the future. The bundle id is unique to an instance of OSGi so it will load the correct version of the bundle.
I suggest browsing a bit the Javadoc deprecation descriptions, the replacement is documented. I found the following code, but did not test it.
String contributor = e.getDeclaringExtension().getContributor().getName();
Bundle bundle = Platform.getBundle(contributor);
Version versionInfo = bundle.getVersion();
Out of curiosity: why do you need to get the version of the extending plug-in? As far as I know, the goal of the extension point mechanism is to detach specific information about the extender, and only the information described in the extension (plugin.xml) or the referenced code is needed.