I'm developing SSRS reports via VS2010 on my local machine.
I need to reference from a certain report to a DLL I wrote, The DLL was built at .net framwork 3.5 and I've placed the dll in the following libraries:
1.C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies.
2.C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin
both on my local machine and the server where SSRS is located.
I've also added rssrvpolicy.config file as following:
<CodeGroup
class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust"
Name="Test"
Description="">
<IMembershipCondition
class="UrlMembershipCondition"
version="1"
Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Test.dll"
/>
Done all that' I've referenced the DLL through the report properties but yet recieved the following error message while previewing the report:
"An error occured during local report processing, The definition of the report X is invalid.
Error while loading code module "Test ...' Could not load file or assembly 'Test ...' or one of its dependenies. The system cannot find the file specified"
Any ideas?
OK found the problem!
Apperntly installing VS2010 on win7 64 bit create two Microsoft Visual Studio 10.0 folders, one in Program Files where I've located my DLL and one in Program Files (x86) where I should have located it.
Once the DLL was put in the correct folder the report recognized it.
Thanks for your reply
Related
I created a simple console application in both .NET Framework 4.8 and .NET 5 (same code in both), but symbols resolve differently across various debugging tools.
If I run both applications, launch Process Hacker, open the process's properties, click on the Threads tab, and open the Stack for the primary managed thread, the .NET 4.8 Stack shows resolved symbols for my classes and methods, but the .NET 5 Stack does not -- it shows hex strings like 0x7ffbac6087a3.
In both cases, calls to System.Console.dll!System.Console.ReadKey() resolve correctly, so I know I have my symbol loading configured correctly (_NT_SYMBOL_PATH = "srv*C:\Source\symbols*https://msdl.microsoft.com/download/symbols"). In both cases, the projects are configured for full debug type and to include debug symbols. In both cases, there is a .pdb to go along with the .exe.
Sysinternals Process Explorer won't display any of that - the bottom of the call stack is 0x0.
If I take a dump of the applications, I can load them into WinDbg Preview and am able to see all of my code as expected. For the .NET 5 application, the normal Stack shows the same thing as Process Hacker (e.g. 0x7ffbac6087a3), but if I run the command !CLRStack -a, those hex values get properly resolved (e.g. 000000BD4F17E840 00007ffbac6087a3 SymbolsCoreConsoleApp.Program.Run() [C:\Source\research\SymbolsCore\SymbolsCoreConsoleApp\Program.cs # 18]).
So, there's the background. Here are the questions:
1.) Why doesn't the Process Hacker Stack resolve symbols for my classes in a .NET 5 application, but it does for the exact same code in a .NET Framework 4.8 application?
2.) Why doesn't Sysinternals Process Explorer display any of my code (just 0x0) for either application? In case it matters, I run procexp64.exe and my machine is x64 Windows 10 Enterprise. If I run 'procexp.exe`, it ultimately launches the x64 version anyhow. Mentioning this in case there is an issue with 32 vs. 64 bit.
3.) Both Process Hacker and Process Explorer have process tabs specifically for .NET (e.g. .NET assemblies and .NET performance), and those tabs only show up for the .NET Framework 4.8 application, but not for the .NET 5 application. Is this by-design or do I have something configured wrong?
4.) In WinDbg Preview, is this behavior by-design? If so, why?
5.) Are there other special things to consider when debugging/analyzing .NET 5/Core applications outside of Visual Studio?
That's a lot of questions, but they're all closely related, and I suspect there may be some fundamental thing(s) that I'm missing here.
Thanks in advance!
EDIT: 20210803 10:55 AM CDT
Per magicandre1981's comment, I installed the nightly of Process Hacker (v3.0.4234).
It still doesn't resolve those symbols.
It does show .NET assemblies and .NET performance tabs for the .NET 5 application now, but there are no values on the .NET performance tab.
EDIT: 20210803 05:05 PM CDT
I ran symchk and dumpbin against both of the applications in case this will help anyone diagnose the problem.
.NET 5
net5.0> $> pwd
C:\Source\research\SymbolsCore\SymbolsCoreConsoleApp\bin\Debug\net5.0
net5.0> $> & 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\symchk.exe' .\SymbolsCoreConsoleApp.exe /r
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
net5.0> $> & 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30037\bin\Hostx64\x64\dumpbin.exe' /PDBPATH:VERBOSE .\SymbolsCoreConsoleApp.exe
Microsoft (R) COFF/PE Dumper Version 14.29.30040.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file .\SymbolsCoreConsoleApp.exe
File Type: EXECUTABLE IMAGE
PDB file 'C:\Source\research\SymbolsCore\SymbolsCoreConsoleApp\bin\Debug\net5.0\apphost.pdb' checked. (File not found)
PDB file 'D:\workspace\_work\1\s\artifacts\obj\win-x64.Release\corehost\cli\apphost\standalone\Release\apphost.pdb' checked. (File not found)
PDB file 'C:\WINDOWS\symbols\exe\apphost.pdb' checked. (File not found)
PDB file 'C:\WINDOWS\exe\apphost.pdb' checked. (File not found)
PDB file 'C:\WINDOWS\apphost.pdb' checked. (File not found)
Summary
2000 .data
2000 .pdata
9000 .rdata
1000 .reloc
1000 .rsrc
14000 .text
1000 _RDATA
net5.0> $> & 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\symchk.exe' .\SymbolsCoreConsoleApp.dll /r
SYMCHK: SymbolsCoreConsoleApp.dll FAILED - SymbolsCoreConsoleApp.pdb mismatched or not found
SYMCHK: SymbolsCoreConsoleApp.dll FAILED - No CodeView information found.
SYMCHK: FAILED files = 2
SYMCHK: PASSED + IGNORED files = 0
net5.0> $> & 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30037\bin\Hostx64\x64\dumpbin.exe' /PDBPATH:VERBOSE .\SymbolsCoreConsoleApp.dll
Microsoft (R) COFF/PE Dumper Version 14.29.30040.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file .\SymbolsCoreConsoleApp.dll
File Type: EXECUTABLE IMAGE
PDB file found at 'C:\Source\research\SymbolsCore\SymbolsCoreConsoleApp\bin\Debug\net5.0\SymbolsCoreConsoleApp.pdb'
Summary
2000 .reloc
2000 .rsrc
2000 .text
.NET 4.8
Debug> $> pwd
C:\Source\research\SymbolsFramework\SymbolsFrameworkConsoleApp\bin\Debug
Debug> $> & 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\symchk.exe' .\SymbolsFrameworkConsoleApp.exe /r
SYMCHK: SymbolsFrameworkConsoleApp.exe FAILED - SymbolsFrameworkConsoleApp.pdb mismatched or not found
SYMCHK: FAILED files = 1
SYMCHK: PASSED + IGNORED files = 0
Debug> $> & 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30037\bin\Hostx64\x64\dumpbin.exe' /PDBPATH:VERBOSE .\SymbolsFrameworkConsoleApp.exe
Microsoft (R) COFF/PE Dumper Version 14.29.30040.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file .\SymbolsFrameworkConsoleApp.exe
File Type: EXECUTABLE IMAGE
PDB file found at 'C:\Source\research\SymbolsFramework\SymbolsFrameworkConsoleApp\bin\Debug\SymbolsFrameworkConsoleApp.pdb'
Summary
2000 .reloc
2000 .rsrc
2000 .text
EDIT: 20210803 07:54 PM CDT
Per hanpassant's comment, here is the project file (it already had the DebugType set to full).
SymbolsCoreConsoleApp.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<DefineConstants>DEBUG;TRACE</DefineConstants>
</PropertyGroup>
</Project>
EDIT: 20210803 08:40 PM CDT
Here are a few screenshots in case it wasn't clear from my explanation.
Notice the 0x7xfbb03a8 addresses instead of resolved symbols.
Notice the resolved symbols for SymbolsFramework.ConsoleApp.Program instead of the unresolved 0x7xfbb03a8 addresses.
Notice the 0x0 address instead of any resolved symbols.
The .NET Assemblies tab shows up for .NET 5 and appears to populate correctly.
The .NET Performance tab shows up for .NET 5, but it has no values.
I opened an issue with Process Hacker on GitHub and it was closed a few days back with a fix in the nightly build. I confirmed that it now works as expected.
I'm getting the same error message as in this question: Could not load type 'Microsoft.Cct.Services.Sqm.IWatSqmService' Unfortunately, I cannot upgrade to Azure SDK 2.9, as the top answer there suggests.
Specifically, I get this error in a message box whenever I try to package my Azure Cloud Service project:
What's interesting is that I can start the same project in the emulator, which I would assume involves packaging it.
Things I've tried:
Ensuring that I only have version 2.8.2 of the emulator installed (I may have had 2.9 installed initially)
Reinstalling version 2.8.2 of the SDK
Manually copying the Windows Azure Tools from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0 to the v14.0 equivalent.
Ensuring that C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.8 exists
Reinstalling Visual Studio (so you know I'm desperate!)
And I've no idea what to try next. I can't work out which DLL is supposed to hold the Microsoft.VisualStudio.WindowsAzure.Services assembly, I can't find any references in any config files, and all the Google hits seem to point back to the SO question linked above.
What's going on? And how can I fix it?
In case I'm being an idiot, here's all the Azure-related things I've got installed:
Also (just in case it's relevant) I'm on Windows 7 SP1.
Update 17/01/16
Following some advice from the excellent Rest Azured Slack channel, I've tried using ProcMon and Fusion Log to diagnose this (spoiler: without success)
ProcMon filtered to that assembly returns nothing:
Fusion log (set to log everything) yields lots of entries like this:
* Assembly Binder Log Entry (17/01/2017 # 11:52:02) *
The operation was successful. Bind result: hr = 0x0. The operation
completed successfully.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under
executable C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = Microsoft.VisualStudio.WindowsAzure.Services, Version=1.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio
14.0/Common7/IDE/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = devenv.exe Calling assembly
: Microsoft.VisualStudio.WindowsAzure, Version=2.9.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
=== WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with
Assembly.Load(). WRN: No matching native image found. LOG: IL assembly
loaded from C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\Microsoft.VisualStudio.WindowsAzure.Services.dll.
When I explore the DLL mentioned, I can find Microsoft.Cct.Services.Sqm, but it doesn't contain a type IWatSqlService:
This feels like it's the crux of the issue, but I've no idea what to do next. Presumably I'd need to replace the DLL with a version that does define IWatSqlService, but I'm not sure where I'd get one. Or, for that matter, why it would even be necessary.
Next stop is probably a full wipe of the machine.
I've had the same problem, and solved it by not using the Web Platform Installer.
Download all parts (Microsoft Azure SDK for .NET - 2.8.2) from the Microsoft site: https://www.microsoft.com/en-us/download/details.aspx?id=50041 and follow the instructions how to install them.
For anyone else with this problem. I ended up resolving this by nuking it from orbit. Fresh install of Windows, reinstall VS and the SDK.
Confusingly, you can also see this error when you add a new
<setting name="TODO" />
element to your *.csdef file but either:
forget to add the corresponding <setting name="TODO" value="TODO" /> element to every *.cscfg file, or
accidentally add a duplicate <setting name="TODO" value="TODO" /> element to any of the *.cscfg files.
I am creating Datadriven Unit(MS Unit Test) Test using Excel(*.xlsx) file as data source.
it is erroring out with the following error
Result Message: The unit test adapter failed to connect to the data
source or to read the data. For more information on troubleshooting
this error, see "Troubleshooting Data-Driven Unit Tests"
(http://go.microsoft.com/fwlink/?LinkId=62412) in the MSDN Library.
Error details: ERROR [IM014] [Microsoft][ODBC Driver Manager] The
specified DSN contains an architecture mismatch between the Driver and
Application
I have set the Copy to Output directory : always for the DateRangeTest.xlsx
I also tried defaultdir=.\;, defaultdir=.;, and defaultdir=c:\projectName\bin\debug\;
Here is the section from app.config
<configSections>
<section
name="microsoft.visualstudio.testtools"
type="Microsoft.VisualStudio.TestTools.UnitTesting.TestConfigurationSection, Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
/>
</configSections>
<connectionStrings>
<add name="DateRangeConstr"
connectionString="Dsn=Excel Files;dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
</connectionStrings>
<microsoft.visualstudio.testtools>
<dataSources>
<add name="DateRangeTestDataSource"
connectionString="DateRangeConstr"
dataTableName="Sheet1$"
dataAccessMethod="Sequential"/>
</dataSources>
</microsoft.visualstudio.testtools>
There are (2) options here - you can either remove the DSN requirement or install the opposite Excel/Access runtime bitness of the Office product you have installed.
Option 1 - remove DSN from Connection String
Change from this:
<add name="DateRangeConstr"
connectionString="Dsn=Excel Files;dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
To this:
<add name="DateRangeConstr"
connectionString="dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
Option 2 - Install ODBC Drivers for Opposite Bitness
For Office x64, install Microsoft Access Database Engine 2010 Redistributable for x86 (AccessDatabaseEngine.exe)
For Office x64, install Microsoft Access Database Engine 2010 Redistributable for x64 (AccessDatabaseEngine_x64.exe).
This fix should be the same whether you have Office 2010 or Office 2013.
To test this change - you should be able to configure the Excel Files DSN for both x86 and x64 once installed.
32-bit ODBC: %WINDIR%\SysWOW64\odbcad32.exe
64-bit ODBC: %WINDIR%\System32\odbcad32.exe
Click on "Excel Files" and then click "Configure" and you should see a dialog. If an error occurs when you click "Configure" - you don't have the proper office driver installed for that bitness.
We need not to install anything to our system to run the external excel data driven unit tests.
We need to simply run the Data Source Wizard present under Visual Studio Data Source Explorer.
Watch this video. This Tutorial tells how to run Data Driven (Parameters) unit tests using Visual Studio Testing Tools.
When I go to the "Setup Property Pages" in a Visual Studio Setup project and view the Prerequisites, I see a warning:
Prerequisite could not be found for bootstrapping
I did the following things:
Added a new folder in: "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages" with my package
Restarted VS2010
(Even rebooted my pc)
Warning is still visible on that package.
Next I've added a .VSBootstrapperManifest file in the Packages directory ( C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages )
Restarted VS2010 again but that didn't help either, same with reboot.
Any suggestion what could be wrong?
This worked on my Win7 x64 machine, but this doesn't seem to work anymore on my Win8 Pro x64.
Thanks in advance.
update:
When I open the Product.xml file from my package I see these XML lines:
<InstallChecks>
<RegistryCheck Property="FoxProOleDbInstalled" Key="HKCR\CLSID\{...-..-..}\InprocServer32" />
</InstallChecks>
When I search that key {...-..-..} in my registry I cannot find it at the location HKCR\CLSID{...-..-..}
But I can find it at this location:
HKEY_CLASSES_ROOT\ Wow6432Node \CLSID\ {...-..-..}
Can I just add another line inside the InstallChecks-tag in the Product.xml ?
How will the RegistryCheck tags be checked in that file (AND? OR?)
(I think all InstallChecks need to be true but I'm not sure, the documentation is not so clear: http://msdn.microsoft.com/en-us/library/ms229432(v=vs.80).aspx )
If you are developing windows 8 store/metro apps in "windows 8 pro".
Use visual studio 2012 instead of vs2010.It will work.
Where is TextTransform.exe located?
I'm trying to implement the solution in this post:
Get Visual Studio to run a T4 Template on every build
However I'm getting an error
"'TextTransform.exe' is not recognized as an internal or external command,
operable program or batch file."
I have been looking through the program files, however not sure where TextTransform.exe is located.
It should be below
\Program Files\Common Files\Microsoft Shared\TextTemplating\
see: http://msdn.microsoft.com/en-us/library/bb126245.aspx
Anyone coming to this question that's using VS 2017 or later should be using vswhere to locate this file. #codingdave's comment is the closest but that still won't work on many computers.
I've added an example to the Microsoft Docs article feedback that shows how to do this with Powershell.
#the path to VSWhere.exe is always in programfiles(x86)
$progFilesx86Path = [System.Environment]::ExpandEnvironmentVariables("%programfiles(x86)%")
$vsWherePath = Join-Path $progFilesx86Path "\Microsoft Visual Studio\Installer\vswhere.exe"
# this tells vswhere to use paths of the latest version of visual studio installed
# to locate this exe anywhere in those paths, and return a single textual
# value (not a json object or xml payload)
$ttExe = & $vsWherePath -latest -find **\TextTransform.exe -format value
if (-Not(Test-Path $ttExe)){
throw "Could not locate TextTransform.exe"
}
#then to invoke a transformation
& "$ttExe" c:\Source\YourTransform.tt
From #codingdave's comment
For VS2017, VS2019 location of TextTransform.exe will be
C:\Program Files (x86)\Microsoft Visual Studio\<<Version>>\<<Edition>>\Common7\IDE
Version -> (2017/2019)
Edition -> (Community/Professional/Enterprise)
And in pre build event we can use macro like
"$(DevEnvDir)\TextTransform.exe" "$(ProjectDir)AssemblyInfo.tt"
I would recommend trying this over that solution: http://www.olegsych.com/2010/04/understanding-t4-msbuild-integration
If you don't have VS 2010, though, I suppose you're stuck doing it the hard way.