Is it possible to query for defects across an entire workspace?
We have defects that come in from our customer support portal that have a special "support id" field set, but they can be distributed to any of our projects. I'd like to query for any such open defects across all the projects and sub projects in our workspace, but I think project scoping will prevent this.
Is there any way to do this? I suppose I could put all our projects under one "super" project in the workspace and do it that way, but it seems like that would add a lot more navigation trouble for everybody in the organization to help solve this problem.
You actually can do this by not specifying a project in your query (specifically setting project to null). Here is an example using the RallyDataSource in the App SDK:
var rallyDataSource = new rally.sdk.data.RallyDataSource('__WORKSPACE_OID__',
'__PROJECT_OID__',
'__PROJECT_SCOPING_UP__',
'__PROJECT_SCOPING_DOWN__');
var queryConfig = {
type: 'defect',
key: 'defects',
fetch: 'Name,State,Severity',
project: null //query all projects in the workspace
};
rallyDataSource.findAll(queryConfig, displayDefects);
Related
I have a solution which builds in vs. When I load it with roslyn like so:
var workspace = MSBuildWorkspace.Create();
var solutionPath = #"c:\path\to\my.sln";
var solution = workspace.OpenSolutionAsync(solutionPath).Result;
then all of the projects have 0 metadata references.
If I try and get a type from a referenced assembly like this:
var compilation = solution.Projects.First().GetCompilationAsync().Result;
var myType = compilation.GetTypeByMetadataName("SomeTypeNanme);
it never finds the type. If I manually add metadata references like this:
var project = project.AddMetadataReference(AssemblyContaningTheType);
Then it can find the type.
My solution targets .NET Framework 4.5.2, in case that matters
Is this the only way to resolve the references, ie adding the metadata references manually? Can it not be done through the fact that the references are all in the csproj? How can I know what all the references that I need to add?
Ideally I'd like to have references resolved automatically, but would be ok with pointers on building all neccessary metadata references from the info in the project files...
As far as I can tell, it could be related to this issue, or maybe this one which leads to this open ticket.
Quoting the latter
Empty MetadataReferences for project referencing other project from same solution
Version Used:
2.7.0
Steps to Reproduce:
Create solution with two projects, A and B
Reference project B to project A
Open project A using this code:
var workspace = MSBuildWorkspace.Create(additionalProperties);
Project project = workspace.OpenProjectAsync(projectPath).Result;
Expected Behavior:
project.MetadataReferences should contain project's references, such as mscorlib.dll
Actual Behavior:
project.MetadataReferences is empty.
So I finally got around to looking at this again. The solution for me was from this gist:
https://gist.github.com/DustinCampbell/32cd69d04ea1c08a16ae5c4cd21dd3a3
Which basically forces a consistent version of MSBuild.
First add a reference to Microsoft.Build.Locator (it says it works for MSBuild 15, but it worked with 16 for me).
then add this line:
MSBuildLocator.RegisterDefaults();
somewhere in the bootstrapping, before you open the solution with an MSBuildWorkspace.
I have two Visual Studio solutions SolutionA and SolutionB, each of them containing several web application projects in ASP.NET Core 1.1. The configuration of the projects is handled by the commonly used appsettings.json.
I'd like to outsource some of the config keys that are used in common from the projects of the both solutions, so that the common values don't have to be stored redundantly in both solutions. Is there any way to reach this goal? While I found some way to do it for projects that belong to the same solution (see Andrew Lock's blog post), I didn't find any way to do it for projects that are stored in different solutions.
If you know where your AppSettings.json file is located, you can use the following code:
var settingPath = Path.GetFullPath(Path.Combine(#"../../appsettings.json")); // get absolute path
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile(settingPath, optional:false, reloadOnChange:true);
In your project there would be an automaticall reload if the file changes. Hope you're searching for this solution
I'm using the BigQuery Web UI to derive several custom tables from our firebase app event data (one big messy table). This allows other display services (in this case Google Data Studio) to display dynamic dashboards and reports.
The problem is that I can't get my derived tables to auto-update each morning. Instead I have to manually re-run the queries in order to refresh the data. Is there a way to configure these jobs to run in the interface? Or do I have to configure jobs somewhere else? Thanks.
While not as simple as scheduled table materialization, you could set up a cron in Google App Engine to kick off your daily query job. I believe this should easily remain within the free tier.
There are docs for both Python and Java.
It looks like you can schedule daily tasks with Apps Script as well.
Here is a quick example I tried.
Go to: script.google.com
Enable advanced services (Menu > Resources > Advanced Services ..., then turn on BigQuery).
Name the default function something more descriptive, I chose "rebuildTables".
Click the "triggers" button (looks like a clock with a tack sticking out of it).
Give your project a name. I chose "BigQuery -- Build Daily Tables".
Now you can add a trigger. For example: time-driven, day timer, 5am to 6am
Edit the script. Borrowed from here: https://developers.google.com/apps-script/advanced/bigquery
function rebuildTables() {
// Replace this value with the project ID listed in the Google
// Developers Console project.
var projectId = 'EXAMPLE_PROJECT';
var request = {
configuration: {
query: {
query: 'SELECT 17;',
destinationTable: {
"projectId": "EXAMPLE_PROJECT",
"datasetId": "EXAMPLE_DATASET",
"tableId": "EXAMPLE_TABLE"
},
writeDisposition: "WRITE_TRUNCATE"
}
}
};
// Fire-and-forget.
BigQuery.Jobs.insert(request, projectId);
}
I have recently started diving into the new .net core along with asp.net core mvc. There have been several issues that I have come across but have been able to get most of them answered on my own. The one that has really stumped me is the use of NPoco.
How are you supposed to create the database instance?
The documentation reads:
IDatabase db = new Database("connStringName");
List<User> users = db.Fetch<User>("select userId, email from users");
This is not correct for DNXCORE50 as this constructor has been excluded for DNCORE50
I have also attempted this:
IDatabase _db = new Database(new SqlConnection(ConnStr));
_db.Single<string>("SELECT Username FROM dbo.Member");
When this code is ran I get a 'NullReferenceException'
Does anyone know how to get NPoco working properly?
There are other people having the same issue. This has been reported as issue #293 on NPoco GitHub repository.
The current workaround for this problem is to list the DbProviderFactory as shown below.
IDatabase _db = new Database(new SqlConnection(ConnStr),
DatabaseType.SqlServer2012, SqlClientFactory.Instance);
_db.Single<string>("SELECT Username FROM dbo.Member")
I'm working on a service that will download a .NET solution from a repository and build it (not unlike a continuous-integration build service). What I want to know is, using MSBuild programmatically via the Microsoft.Build namespace classes, can I can load the solution and project(s) into memory and build it without first saving them to disk in a temporary folder?
I'm still learning MSBuild and trying things, but I figure someone on Stack Overflow has tried this and has some insight.
I can't speak to whether this is a good idea or not, but it's possible to do.
ProjectInstance has a constructor that accepts a ProjectRootElement, which can be constructed via the Create(XmlReader) method. And as you may know, XmlReader can be attached to various Streams including a MemoryStream.
Here's how something like this may look:
var xmlReader = XmlTextReader.Create([your existing memory stream]);
var project = ProjectRootElement.Create(xmlReader);
var buildParams = new BuildParameters();
var buildData = new BuildRequestData(new ProjectInstance(project),
new string[] { "Build", "Your Other Target Here" });
var buildResult = BuildManager.DefaultBuildManager.Build(buildParams, buildData);
After researching MSBuild and all the involved components, it appears as though it's necessary to have the entire project set up on the file system before being able to build it. Unfortunately, what I'm trying to do just can't be done with the provided toolset.