Perhaps not a fully fledged programming quiestion, but to help drive the quality and enforce some standards throughout the application I am working on I want to use FxCop.
If I try to integrate into into Visual Studio 2005 as an external tool using the command line
/c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
When running the tool it fails to resolve Web.Servies.2.dll in my resource layer.
I also have a business layer that references my ResourceLayer which also fails to resolve (i.e. running FxCop on the Business layer results in a error saying the ResourceLayer.dll cannot be referenced)
If I run FxCop standalone it works no problem.
Has anyone else managed to get around this problem?
I have managed to fix this.
by setting the command line to
/c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" /directory:"C:\svn\projectDir\ExternalDLLs"
where C:\svn\projectDir\ExternalDLLs is a collection of all external Dlls required by the application.
Related
I tried to create T-SQL Static Code Analysis Rules in Visual Studio 2010 to analyze T-SQL code in Visual Studio 2010 database project. But I couldn’t find a way to debug them.
Does anyone know how to debug these rules?
You need to run another instance of VS2010 and open a dbproj to debug. You can do this by setting Debug option to "Start External Program" and point it to VS2010 exe (C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe). Hope this is what you are looking for..
I found this blog post which covers how to make and debug tsql static code analysis. Good luck!
http://blogs.msdn.com/b/gertd/archive/2009/01/01/creating-t-sql-static-code-analysis-rules.aspx
Here are the important bits in a nutshell:
Start with a project that builds and works I'd hope
From a working project, create post build tasks:
copy "$(TargetDir)$(TargetName)$(TargetExt)" "$(ProgramFiles)\Microsoft Visual Studio 10.0\VSTSDB\Extensions\$(TargetName)$(TargetExt)" /y
copy "$(ProjectDir)$(TargetName).Extensions.xml" "$(ProgramFiles)\Microsoft Visual Studio 10.0\VSTSDB\Extensions\$(TargetName).Extensions.xml" /y
(the article mentions copying these files to your GAC, but I didn't need to do that)
Build, open a new db project, and ensure that your rules got copied and work
Set some break points (like creating a default constructor for the rules, and setting a break point there so you can se it gets loaded, then again inside of the rule)
Under debug settings go to: Start Action – Start external program “C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe”
Start debugging, a new VS will load
In the new VS, open the db project, you should see your break points in the constructors getting hit. This means that your files coped and you are correctly debugging your code
Now build the db, this should trigger the rest of your debug points.
Peace.
I'm trying to set up some build scripts for continuous integration and I'm finding something weird.
My solution compiles fine from Visual Studio 2010, but fails with an error when I build the exact same thing from the command line with MSBuild.
Here's the error I get from the commandline build.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.WinFX.targets(269,9):
error MC1000: Unknown build error,
'Cannot resolve dependency to assembly 'Microsoft.Windows.Design.Extensibility, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.'
[C:\Dev\Market Watch\src\Console\MarketWatch.Console\Rbnz.MarketWatch.Console.csproj]
I've checked through all my source code for references to Microsoft.Windows.Design.Extensibility and haven't found any at all. I've also checked all the binaries we reference from this project, including some DevExpress libraries.
My MSBuild commandline looks like this:
MsBuild.exe c:\Dev\MarketWatch\src\Capture\Capture.sln
/t:rebuild
/verbosity:quiet
/filelogger
/fileloggerparameters:LogFile=c:\Dev\MarketWatch\build\Logs\capture.msbuild.log
Is there something missing that I should include on the MsBuild commandline to make commandline builds work just the same as those run by Visual Studio?
Update 14/4
I'm getting these errors despite running the build script from a Visual Studio command prompt.
I hope you solved the problem, but for future reference:
I just had the same problem, and it comes from DevExpress '.design' assemblies. You're actually not supposed to reference those in your project. Remove all references to DevExpress assemblies ending with '.design' and it should work.
You should initialize paths to find assemblies, tools and so on. Call vcvarsall.bat before calling msbuild:
call "%ProgramFiles%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
Or open VS2010 command line console and call your script from it. Both actions has the same effect.
EDIT: I couldn't understand one thing - google for your question says that you use Reflection in a wrong way, and one of possible solutions is described here. Am I right?
I recently encountered the same issue.
The Error was thrown on our VSTS-BuildAgent.
After following all advices from Devexpress sites (including Project-Upgrade), the Error was still there.
To be honest, we are mixing WinForms and WPF for a smooth migration from Winforms to WPF, so basically not an everyday-problem.
Anyway, i was able to fix this, by adding all needed references to WPF-Project again, even if they are all already referenced in the Start-Project, which is Winforms.
After this move, the BuildAgent was able to succeed the Build.
I'm trying to use an external library DevExpress.XtraTreeList.v8.1.dll in my vsto office addin built using VS2010 beta 2. I am getting the following compile time error:
DevExpress.Utils.AppareanceObject threw an exception --> System.NotSupportedException.
The error message goes on to say that for compatibility reasons I can use the NetFx40_LegacySecurityPolicy switch.
I've tried putting this config variable in all of the following locations:
1) my applications config file.
2) C:\Windows\Microsoft.NET\Framework\v4.0.21006\msbuild.exe.config
3) C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\dev.exe.config
None of these have resolved the problem. Here were the references I've used.
re-enable cas
msdn.microsoft.com/en-us/library/ee191568(VS.100).aspx
How do I get rid of this error so I can build the application in vs 2010?
LC.exe fails to process license information of devexpress 9.1.4 dlls
Update: Looks like this program is related to lc.exe. create a file called lc.exe.config that contains
<NetFx40_LegacySecurityPolicy enabled="true"/>
under C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\ (NETFX 4.0 Tools) solves the problem
This does work, however, you'll also need to create a file for devenv.exe.config to edit form designer changes, and the side effect of that is that COM references in project's will give obscure errors.
The end result, is that we really need an update from DevExpress on this. Allegedly a beta fix with a 2010.1 release is due any time now, come on DevExpress, hurry up! :)
Here is a problem with specific StyleCop configuration.
I've got a total of two Settings.StyleCop files in my Visual Studio .Net solution folders.
The first is placed at the folder root with chosen rules for the team.
As I want to disable some rules for a specific project, I've put another Settings.StyleCop file in the corresponding project folder.
The results are:
when launching analysis from Visual Studio IDE (Run StyleCop), the project specific file is considered and no violation occurs.
when launching analysis from StyleCopCmd (command tool) the project specific file seems to be ignored and some violations occur.
when launching analysis from MSBuild target the project specific file seems also to be ignored and some violations occur.
Did I miss something with StyleCop configuration to have different results from ?
I'm using: Windows XP StyleCop 4.3 MSBuild 3.5 SP1 MSBuild Extension Pack 3.5.0.0 StyleCopCmd 0.2.1.0
The problem seems to be the same with StyleCop 4.3.1.3 and MSBuild Extension Pack 3.5.3.0
Regards,
Olivier.
I have a DSL Tools solution.
I need to add a weak-named reference to this project.
Because the DSL Tools project DLL is strong-named i cannot used the weak-named DLL.
I cannot make the DLL strong-named because i cannot recompile it.
I tried to make my DSL Tools project DLL weak-named by going to the Dsl and DslPackage project properties and unchecked the option "Sign the assembly" in the Sigining tab.
Then i compile it.
The error list gives the following error
"gacutil.exe" exited with code 1
Looking at the VS2005 output window i see gacutil is being called
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"
After that i used the command prompt and the gacutil.exe error displays as this:
Z:\>"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe" -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"
Failure adding assembly to the cache: Attempt to install an assembly without a strong name
I don't know why and how gacutil.exe is being called.
I looked at the project and solution properties and there is no option configured to call gacutil.exe.
I even looked inside every file for "gacutil.exe" but i found nothing.
What i really want is to be able to use the weak-named DLL that i cannot make strong-named.
As a result of this, i've been trying to make my DSL Tools DLL weak-named but i can't.
Any help on how i can workaround this?
Many thanks in advance,
Luís Filipe
Using runtime binding with reflexion is a good solution and works. The other solution I've implemented besides that one is to launch a separate AppDomain and have that AppDomain doing the loading of the assembly and running whatever methods you want. The downside of this approach is the extra complexity and performance. One really has to know what he is doing as he is in practice launching a separate .net application in Visual Studio's process space. The upside is that with some care, you can get type safety all the way.
With the exception of the answer written above,
All add-ins for Visual Studio must be strong-named.
One may workaround some of the issues by loading the assembly on run-time and using reflection to invoke methods.
Regards,
Luís