My company has made extensive investments into a library of custom MSBuild targets files that we use to build our full product. Every project file we have in source control imports at least one custom targets file, which all ultimately end up importing a core targets file that contains the bulk of our general-use targets & properties.
Recently we added a new SSRS project to our solution, and this project (I believe) is the new rptproj format introduced in late 2017--in particular, it declares ToolsVersion="15.0" and imports Microsoft.ReportingServices.MSBuilder.targets from within the VS 2017 install directory.
The problem I'm experiencing is that none of the logical changes I make to the rptproj file appear to do anything; importing our shared targets file doesn't result the execution of any of our targets, such as targets declaring BeforeTargets="BeforeBuild" or even set against the ReportingServices-specific target with BeforeTargets="ReportBuilderTarget".
Furthermore, attempting to set the OutputPath results in exceedingly weird behavior. Declaring an OutputPath such as the following:
<OutputPath>$(SharedOutputPath)SSRS\$(MSBuildProjectName)</OutputPath>
...will result after build in the following folder within the project file's directory:
C:\workspace\solutionfolder\ReportProject1\$(SharedOutputPath)SSRS\$(MSBuildProjectFile)
This is weird because it's not even interpreting the well-known metadata token $(MSBuildProjectName) as a property, and emitting both it as well as $(SharedOutputPath) as string literals into the OutputPath property.
Furthermore, saving the rptproj file in VS results in a total wipe of all customizations to the file.
Reviewing the Microsoft.ReportingServices.MSBuilder.targets file, it seems as though it does some extensive gutting of the base Microsoft.Common.targets file, but in no way that I can imagine would prevent the basic usage of MSBuild properties or anything.
That's about the the extent of my MSBuild knowledge though so I'm not sure where to take it from here.
Overall it seems like MSBuild support for rptproj files is somewhat half-baked, but am I missing something?
Is it possible to customize Visual Studio 2017 SSRS rptproj MSBuild files?
As workaround, yon can build the project with MSBuild command line.
As test, I overwrite the default OutputPath for SSRS rptproj to:
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<FullPath>Debug</FullPath>
<OutputPath>bin\Debug\$(MSBuildProjectName)</OutputPath>
...
</PropertyGroup>
And add a custom target in the .rptproj file:
<Target Name="Test" BeforeTargets="BeforeBuild">
<Message Text="$(OutputPath)"></Message>
</Target>
Then I build the project with MSBuild command line:
msbuild "<ProjectPath>.rptproj" /property:Configuration=Debug
As result:
And the build file build.obj was generated in the bin\Debug\Report Project1 folder.
Hope this helps.
Related
I am attempting to publish an application from visual studio that has files in the solution. After instilling the program and executing it I get this error.
Could not find file
'C\Users[User Name]\AppData\Local\Apps\2.0\7D4MADG.G94\9BLZYH2N.QOP\wdts..tion_0000000000000_0003.0000_8e564612a360b47a\wdAttrColSettings.xml
I need to know what I need to do to have the files in the Solution Items folder put in the wdts..tion_0000000000000_0003.0000_8e564612a360b47a folder when the application is installed.
In my brief experimentation in Visual Studio 2019, it doesn't look like you can copy Solution Items to the output directory.
This is, presumably, because there's no actual project (i.e. MSBuild or whatever) that would define those actions.
If you put those files inside one of the projects, you can use the "Copy to Output Directory" property.
When I integrated SonarLint into my VS solution, I got a SonarLint.xml file ref. for every project. I wonder, how it is used? Can I remove this reference? Couldn't find any documentation about it.
When I integrated SonarLint into my VS solution, I got a SonarLint.xml file ref. for every project.
This is needed and by-design. The file contains code quality rule parameters used by SonarLint. Example parameter:
<Rule>
<Key>S103</Key>
<Parameters>
<Parameter>
<Key>maximumLineLength</Key>
<Value>200</Value>
When you bind or update your solution from SonarQube, a master SonarLint.xml file gets downloaded into your solution's .sonarlint folder; and a soft-link file to this master file is added to every project being analyzed.
(The SonarLint NuGet apparently does not or cannot access the master SonarLint.xml file, so it needs a project-level SonarLint.xml soft-link file.)
When in a .sln file, you have the default choices of 'Debug' and 'Release'. From what I understand these are 'build settings' of some sort differ depending on the kind of build you are doing?
I recently played around with creating my own settings, and found (much to my surprise) that creating the configuration name didn't seem to create the symbol as recognized by:
#if MY_SHINY_NEW_SYMBOL
Console.WriteLine("TESTING MY SYMBOL");
#endif
And on the Microsoft docs I can see that there is code to allow you to actually define the symbol (presumably separately from just creating one in the Configuration Manager):
#define DEBUG
// ...
How do these symbols work and where are they configured?
i'm asking because I accidentally created a symbol called 'local'. I deleted it and then created a symbol called 'Local'. And I'm getting compile errors because it seems that the 'local' symbol still exists and I can't overwrite it with a symbol using a different case.
I haven't configured the symbol at all, I'm using the variable $(ConfigurationName) in my pre-build event commands.
I'm actually fairly sure this is a Visual Studio bug, since I would think that deleting a configuration, recreated the same configuration with different case, would NOT result in the original configuration reappearing.
Build configurations become MSBuild variables that can be referenced in MSBuild properties in the csproj file (remember that .Net project files are actually MSBuild scripts).
In particular, the Visual Studio Project Properties window will let you set most properties on a per-configuration basis (by wrapping it in a conditional block).
In particular, the DEBUG symbol is set like this (you'll see this in every csproj file, but a bit less simple):
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
...
<DefineConstants>DEBUG;TRACE</DefineConstants>
...
</PropertyGroup>
You could also replace this and set a symbol for the configuration directly:
<DefineConstants>$(Configuration)</DefineConstants>
However, VS is likely to change that if it saves your project file.
In the new Visual Studio 2015 and the Web Essentials plugin, they've removed the function to compile certain files like Less files. Instead they suggest to use Gulp tasks.
While I applaud this decision and understand how to configure Gulp to compile the Less files, but because this is not an ASP.NET 5 application, the new files are not automatically added to the project and as such do not get copied when using the Publish function of VS2015.
As I see it the only way to get these file to copy is to manually add them to the project. This seems a but counter intuitive, if you create a task to compile **/*.less you have to look in your entire project to find the generated css files and add them all manually.
Am I just doing something wrong or is this just the way it works now?
Don't add the files manually, it is pretty easy to add them with a target in your project file. This is how we do it and we also use the gulp-rev package which modifies our filename dynamically (so they will not be cached by a browser). Here is how our BeforeBuild target from our .csproj file looks like:
<Target Name="BeforeBuild">
<Exec Command="BeforeBuild.bat" WorkingDirectory="$(ProjectDir)" />
<ItemGroup>
<Content Include="Scripts\Output\**\*.js" />
<Content Include="Content\**\output\**\*.css" />
</ItemGroup>
</Target>
And in our case when we publish all the generated js files from Scripts\Output\all_folders\ will get published too even though they are not in the csproj (and the same for the generated css files)
For those who preferred the "Web Essentials" method of compiling Less, Sass and CoffeeScript files, Mads Kristensen has published a new VS 2015 extension named Web Compiler. Try it. Also see his Bundler & Minifier extension for additional functionality removed from Web Essentials.
Using SQL2008R2:
I am trying to create a dataset that is simply the result of an external assembly's return method(s), but everything I can find regarding using custom/external assemblies just has a textbox's value set to the external assembly's method's result via an expression.
I simply want Report Server to do the data processing in the external assembly and bind that result to a very simple report.
I found some references to something about MDX but they seem to be a few years outdated and needed to know if this is possible.
Assuming you already have a .dll - Place your dll in the report designer folder (where your RDL is) and the report server folder, somewhere around here:
Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies
Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\bin
Now add a reference to your dll from your report.
With your report open go to Report, Report Properties, References, Add reference, browse to your dll and add it.
Now in a text box properties Value call a method of your dll. It should look something like this:
=MyDllName.ClassName.MyMethodOrSubOrWhatever
This is a great article that can walk you through this:
Assuming you already have a .dll - Place your dll in the report designer folder (where your RDL is) and the report server folder, somewhere around here:
Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies
Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\bin
Now add a reference to your dll from your report.
With your report open go to Report, Report Properties, References, Add reference, browse to your dll and add it.
Now in a text box properties Value call a method of your dll. It should look something like this:
=MyDllName.ClassName.MyMethodOrSubOrWhatever
This is a great article that can walk you through this: http://support.microsoft.com/kb/920769
P.S. Another option, if you don't want the web server doing the heavy lifting, is to use stored procedures. However, in our experience with very large database systems, it is much easier to scale up the web servers than it is to scale up the database servers so we do much of the heavy lifting on the web servers.
If you need a data set that is generated by custom .NET code, you can either set up a web service (here's a good tutorial), or you can set up a custom "data processing extension".
A data processing extension will allow you to choose a new data source in the SSRS report designer, and this data source will run custom .NET code. The full description is on MSDN, but here are the basic steps:
Create a new class library project
Implement all of the required extensions (and any desired optional ones)
Copy the DLL to the SSRS bin folder
Edit the SSRS config file to register your extension (by specifying the fully qualified name of your IDbConnection class)
You can find working examples from both CodePlex and Microsoft.