FxCop must base itself on some internal dictionary.
Does it use Word dictionaries if they are installed?
When running FxCop on my build server it doesn't find any spelling errors, but on my developer machine it does.
I am aware of the custom dictionary, but it is not the issue in this case. On the build server it accepts any word.
This depends on the version. FxCop 1.35 uses Microsoft Office's spell checking, but FxCop 1.36 ships with the spell checker libraries.
If you're using 1.35, I guess Word is installed on your dev box, but not on the build server.
Actually Word 2007 + proofing tools are installed on both boxes. But I will accept and move towards upgrading from 1.35 -> 1.36.
Only difference I can find is that Word 2003 + proofing tools -have been- installed on the developer machine and not on the build server.
Related
Does anyone know how to publish a .NET Core 3.0 application for ARM64?
I can only select "linux-arm" but no "linux-arm64".
Setting linux-arm in combination with x64 also doesnt work. It says the settings are not compatible.
As stated here it should already be supported: https://github.com/dotnet/core/blob/master/release-notes/3.0/3.0-supported-os.md
The linked article points to the supported OSs, not the list of runtime identifiers. An explanation of an RID and a list of common ones can be found in .NET Core RID Catalog. The full list can be found at the CoreFX repo, in runtime.json. linux-arm64 is included but that's only the base OS. There are a lot of specific identifiers like "debian-arm64", "debian.10-arm64", "rhel-arm64" and "ubuntu-arm64". You'll have to use the RID that corresponds to your distribution.
As the RID catalog explains, a runtime identifier consists of the OS, OS version, architecture and optional extra qualifiers.
[os].[version]-[architecture]-[additional qualifiers]
ubuntu-arm64 is the generic Ubuntu version for ARM64 while ubuntu.19.04-arm64 targets Ubuntu 19.04 specifically.
There's no specific version for Raspbian. If you want to target Raspberry in general, you'll have to use linux-arm. If you want to take advantage of the 4GB RAM model, assuming you already use a 64bit OS you may be able to target linux-arm64.
The linux-arm64 isn't available from the publish profile settings, but if you build it using linux-arm and manually edit your .pubxml file afterwards, it works on the pi just fine. As the link you provided shows, it is supported. It seems it hasn't been added to the tooling yet.
Just publish as usual and then edit .pubxml
Change
<RuntimeIdentifier>linux-arm</RuntimeIdentifier>
to
<RuntimeIdentifier>linux-arm64</RuntimeIdentifier>
Then you can publish on a 64bit Raspberry pi.
I am trying to set up references to the CRM 2011 sdk
Microsoft.Xrm.Sdk.dll
Microsoft.Xrm.Portal.dll
Microsoft.Xrm.Client.dll
While trying to use the CrmSvcUtil.exe to generate the early bound types for CRM, I get an error Microsoft.Xrm.Client.CodeGeneration.dll cannot be located. I could not locate the dll in any of the packages that I downloaded using Nuget PM.
Can anybody advise on the usage and how to obtain this?
Use the Early Bound Generator in the XrmToolBox Tool Store. It contains the functionality to generate code using the Xrm.Client. Or if you really just want to use the DLL and do everything by hand, it contains the DLL in the download.
Update
As of March 2020, the EBG no longer supports the deprecated Microsoft.Xrm.Client usage. Hopefully you've transitioned off of that. You can still download older versions of the EBG on NuGet if you're stuck on that client generation.
On the ADL website (http://www.adlnet.gov/scorm/scorm-2004-3rd/#tab-resources) there is the test suite to test for the SCORM 2004 4th conformance. But when I installed it and launched to start a test it gives no click-able "New LMS Conformance Test" button, so can't start a new LMS test. What I did wrong?
Check you Java version. If it's above 7 update 21 I suggest you delete it and install version 6 last update.
You need to install latest version of java. And also jvm
Don't use the latest JRE.
The 4th Ed Test Suite was developed using Java 6 and IE7.
You will need to get back to those. Usually the best way is with a VM with Windows XP sp 2 installed on it. Check the readme that comes with the install, it'll give you the compatible Java and Browser versions.
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.
I'm starting a new development position with a company that implements many of its products in Adobe Flex. What tools should I look to install (Ubuntu Linux options prefered) for Flex development?
As dirkgently said, installing Flex Builder 3 in Linux is a great way to get going. It's quick and easy to get up and running, and since it's based on Eclipse, the overall environment is decent.
That said, I was able to put together a decent Flex-building environment using Emacs and some third-party packages to get everything running under Linux.
Here's a quick rundown of what I used (this isn't comprehensive--just what I can remember):
Flex 3 SDK for Linux
actionscript-mode.el for AS code
highlighting
nxml bundle for MXML code
highlighting
ani-fcsh.el for running fcsh
from Emacs
ECB for code browsing in Emacs
snippet.el for creating code
templates in Emacs
This link was also helpful for getting started. It links to this article which talks about putting together a Flex development environment in Linux. I was able to put together some shell scripts for compiling and running applications.
Note: I didn't do any debugging, though Adobe has some info about it.
Note #2: If you decide to use Flex Builder, it will install the Flash Player 9 debugger version in your browser (you can tell it not to). I would recommend installing version 10's debugger. The builder will output a warning about not supporting the version, but everything else appears to work.
If you can, try Flex Builder 3 alpha for Linux. That's the you can get (not without its set of pet peeves though!). It lacks the following however:
* Design view
* States view
* Refactoring
* Data Wizards
* Cold Fusion - Data Services Wizard
* Web Services introspection
* Profiler
Since AIR/Flex are cross-platform technologies, I don't see why you want to limit yourself to Linux. At least for the time being, I think you are better off with the proper Flex Builder 3 on Windows for development. You can then test your product(s) on Linux.
about debugging - there is an external AIR debugger called MonsterDebugger which is pretty good