none
ain't feelin a lotta love from Google re Win10 - VS2017 - MSMQ RRS feed

  • Question

  • Good afternoon, Gurus.

    I'm having a very basic problem with Win10 - VS2017 - c#.   I'm trying to write a MessageQueue DLL but can't get to first base.  The problem is that statement 1 in the constructor is failing …. VS2017 doesn't recognize the "MessageQueue" class. Some of the documentation says I need to reference "System.Messaging", but VS2017 doesn't recognize that 'using' statement either. Yet other docs state that MSMQ comes standard with Win10, jus' use it.   I dunno; perhaps it IS in some deep, dark, recess of my machine,  but VS2017 sure can't find it.

    So what am I doing to rectify the situation ?  Well sadly, VERY sadly, I am downloading VS2017 once again, thinking that perhaps System.Messaging must be installed manually. The download's completed, and the installation oughtta be finished in another 30 minutes or so, if memory serves.  Then I'll see if the installer offers the loading of optional packages ("System.Messaging").   

    I am TERRIFIED that re-installing VS2017 will be the source of monumental heartache for me. I've gotta lotta code that relies on VS2017. I've learned over the years that changing ANY software (such as, say, VS2017) that's working is exceptionally bad practice : Don't fix what ain't broke,   but I WANT MessageQueueing.

    Can ya help this tired Old Guy out ?

    Wednesday, October 10, 2018 11:47 PM

Answers

  • Yes. Just make it a class library project. It works this way even back to .NET v1.0 days.

    Just that the EXE project that reference it will also need to be a normal .NET 4.X project instead of .NET core project - normal .NET project can reference .NET Core DLL projects, but not the other way round.

    Thursday, October 11, 2018 4:02 AM
    Answerer

All replies

  • I think you're writing .NET Core project.

    System.Messaging is Windows specific therefore is not included in .NET Core runtime libraries, and has no intention to include that.

    You can use this NuGet package if you want to use it under .NET Core, but unless there's a reason for you to go cross platform, it would be much easier and make more sense for you (because it makes no sense to write anything that can only run under Windows with .NET Core) to just re-create a project targeting normal .NET framework 4.X runtime.


    Thursday, October 11, 2018 1:33 AM
    Answerer
  • Thanks for your help, cheong00.

    Is, or can, the normal .NET framework 4.x runtime be a DLL .. I'd prefer a DLL so that I don't hafta re-write (or copy-and-paste) the original version each time I use it ?

    Thursday, October 11, 2018 3:14 AM
  • Yes. Just make it a class library project. It works this way even back to .NET v1.0 days.

    Just that the EXE project that reference it will also need to be a normal .NET 4.X project instead of .NET core project - normal .NET project can reference .NET Core DLL projects, but not the other way round.

    Thursday, October 11, 2018 4:02 AM
    Answerer
  • Good evening, Gurus.

    Say, it occurred to me that there might be other Old Fools such as I that want to use Message Queueing, and don't mind doin' it "Down 'n Dirty". For them I offer this alternate (and simpler!) solution ….

    There is no question in my mind that Cheong's solution is the professional way to do it, but Mr. Cheong is light-years ahead of this Old Fool … I had no clue what he (or she, as the case may be) was talking about, and clearly, I would have spent weeks researching his solution (Again, his is the professional solution; mine is a down 'n dirty work-around).

    The alternate solution is simply to do it as one would in Win7 VS2010 (as I did 4 or 5 years ago on an instrumentation project)…

    1. From the control panel, click "Programs".

    2. Click "Turn Windows features On and Off".

    3. Select and Expand "Microsoft Message Queue (MSMQ) Server".

    4. Select and Expand "Microsoft Message Queue (MSMQ) Server Core".

             4.a. Select all options (or those you think you'll need)
             4.b Select MSMQ DCOM Proxy (what the heck … why not, memory's cheap)

    Now, in your .NET project, select "References", and add  "System.Messaging",

    and add the "using System.Messaging" to your source code as appropriate.

    will this work as well, and as universally, as cheong's ? Certainly NOT. But it seems to work well enough for my very modest requirements (and perhaps your requirements).

    Friday, October 12, 2018 2:24 AM
  • Yes, it can work, unless you try to run your EXE on non-Windows platform, or some machine crazy enough to have .NET Core runtime installed only.

    Just note that you may also experience error if you load any of the incompatible class in your .NET Core code then run the same named class in System.Messaging namespace (some classes in .NET Core do not have all members of full .NET framework) or it may call with a parameter it doesn't support (mainly in those encryption related classes).

    Since this kind of error may occur in places completely unrelated to the place you want to use System.Messaging (say, in another 3rd party library that your project is using), it would be pretty close to impossible to figure out what is going wrong when it happens.

    Better make sure your EXE/DLL's loading libraries in supported sequence - full .NET framework first, than portable subset if needed.





    Friday, October 12, 2018 3:37 AM
    Answerer