I have WCF library project which I have recently done some minor refactoring on eg changing the namespace and changing it location on disk. I also removed the app.config, because I thought the app.config is used by whatever hosts the wcf service.
I have since noticed that I can no longer debug the library using the WcfSvcHost like I used to be able to do. The message I get from Visual Studio is:
'A project with an Output Type of Class Library cannot be started directly.
In order to debug this project, add ana executable project to this solution which references the library project. Set the executable as the startup orject.
I don't want to do as it says, because I didn't need to do this before. Please let me know how to restore the ability to debug it using the WcfSvcHost. On the Debug tab of the project settings, the Command line arguments is still set to: /client:"WcfTestClient.exe"
Not sure what else to try, thanks.
I have observed that changing the output path of the project cause this behavior. To re-enable the debugging using WCFSvcHost/WCFServiceClient leave the output path to default and it should work.
If you changed the project output path you can still run it, you just need to provide some extra parameters to WcfSvcHost like this (enter this in Command Line Arguments in project's debug settings):
/service:ServiceInterface.dll /config:application.config /client:"WcfTestClient.exe"
No need to enter the full path as it will be run from your new project output path
If you still get the 'A project with an Output Type of Class Library cannot be started directly' then you can try changing the start action to 'Start external program' and select the WcfSvcHost.exe in there
You need to build the project in Debug Mode in order to use WcfTestClient and WcfSvcHost
In Debug mode you don't need another project. The Wcf Service Library runs in WcfSvcHost
However if your solution has only Wcf Service Library you need the app.config to configure the endpoints and etc...
Related
I received new project file. Its actually .NET Core Worker Service Project. Created using VS Code. I tried to Manually build the service. but in there no have any dll file. because I only changed the project name after its received. Now I tried to run my project. but I got error. its says
launch: program 'C:My Folders\Glm'
Projects\DBDataService\bin\Debug\netcoreapp5.0\win7-x64\'DBDataService.dll' does not exist
Can you please tell me how to setup my local environment with dll file in VS Code. I am new to VS code actually. How to manually setup dll file in project
VSCode was looking for the DBDataService.dll program, but could not find it.
You only need to configure your environment and then correctly define everything (especially "programs") in your launch.json.
Try to change,
"program": "${file}"
${file} is a predefined variable in VS Code for the current opened file. Refer to：
https://code.visualstudio.com/docs/editor/variables-reference
You can also refer to this post, which may help you:
C# - VS Code - launch:program ... does not exist
Create a debugging file：
https://code.visualstudio.com/docs/editor/debugging
It's a question I see on here but solutions aren't working.
I have a Multi Project Solution set up like so
The sole purpose of the "Console" is to start/stop the "Controller", the "Controller" the handles the "Plugins".
"Console" is a Console Application the other projects are class libraries.
I've just added log4net to the "Controller" project to write logs to the database.
In DEBUG it works perfectly and logs to SQL.
However once built in release, published and deployed it is failing to log.
I've kept all the log4net config within the Controllers "app.config" and know this is being used because the "app.config" has some other settings present.
Attempted Solutions - ALL WORKING in DEBUG but not Published/Released Version
Changed SQL connection string to a USER & Password from Windows
Changed log4net to separate config file and setting build properties to CONTENT and COPY ALWAYS
Using the below code to configure log4net in either he "AssemblyInfo.vb or the "Contoller.vb" file
Assembly: log4net.Config.XmlConfigurator(ConfigFile:="app.config", Watch:=True)
Any potential ideas please?
NOTE:
If I remove the explicit ConfigFile:="app.config" LOGGING DOES NOT WORK
NOTE 2:
Setting an absolute file path on the server for the ConfigFile enabled the Published Installed version to work. Is this the best method?
I am using the TeamCity Visual Studio runner. I want to add a setting that is not accessible from Visual Studio.
/Property:FileAlignment=4096
I typed that directly into the build step "Command line parameters." The build log shows the error:
MSBuild command line parameters contains "/property:" or "/p:" parameters. Please use Build Parameters instead.
I don't understand how to provide this to MSBuild from TeamCity and get rid of this warning!
1. Which kind of parameter should I use?
There are 3 kinds:
Configuration parameters
System properties
Environment variables.
I don't want an environment or system variable because I don't want this build to depend on anything external. I am going to try Config right now, but then I'm not sure I'm filling it in right.
2. How can I tell this parameter is actually getting used?
The build log, which seems only to have navigable/foldable xml-like levels with their program, did not say the build parameters.
You should use "System properties". Don't worry about the name, that's just how TeamCity calls it. They are regular properties. You can add them in "Edit Configuration Settings > 7. Build Parameters".
For example, you can add the system property as follows:
Name: system.FileAlignment
Type: System property (system.)
Value: 4096
Note that TeamCity will insist on the "system." prefix. It doesn't matter because the MSBuild script will still see it as $(FileAlignment).
The TeamCity documentation defines Build Parameters as "a convenient way of passing generic or environment-specific settings into the build script". Configuration parameters provide a way to override some settings in a build configuration inherited from a template. They are never passed to a build. System and Environment parameters are provided to your build script. Environment variables are actually set on the system (I can't find any documentation for this). System parameters are passed to the script engine.
TeamCity automatically provides System variables to the actual command line (it looks like the Visual Studio runner runs msbuild.exe and not devenv.exe). I guess that TeamCity is constructing a command like
cmd> msbuild.exe my-solution.sln /p:FileAlignment=4096
I tried this on my command line, just to make sure that it should work (I added the /v:diagnostic flag). The diagnostic verbosity makes msbuild print all of it's properties to the console. I verified that FileAlignment=4096 was in there.
That /FileAlignment property appears to be a special property that's automatically in any .csproj file. So you should be good to go. You can check the actual parameters that were passed to the build by clicking on any build and viewing the 'Build Parameters' tab. There's a section that shows the "Actual Parameters on Agent".
This was solved. To clarify, Anthony told how to solve the problem in the commandline using MSBuild. It can also be solved on the commandline using devenv, per a ticket with Microsoft, the syntax is:
devenv ..\..\mysolution.sln /Rebuild /Property:Config=Release;Platform=AnyCPU;Filealignment=512
What I wanted, however, was to get Teamcity's "Visual Studio Build" to accept the parameter. This was achieved as follows. In the box for Command line parameters, I entered:
/Property:FileAlignment=filealignment v:diag
Then the output tab for Build Parameters shows:
User Defined Parameters
Name Value passed to build
system.filealignment 512
system.verbosity diagnostic
(This is -754 chars for a comment so must be typed as a post)
hi Anthony, Thank you for replying!
Yes, msbuild on the commandline works fine for me as well and project files may store FileAlignment properties. In our case, upon discussion with Microsoft, it appears necessary that I specify the solution-wide aka build-wide alignment, ie in the command arguments, in addition to fixing the projects (which I have already done).
No parameter that I specify on the GUI item ( /Build Step / Command line parameters/ ) will appear on the tab /Build Parameters/. Of course some will not compile at all.
Also I have even more weird behavior where using
/verbosity:diagnostic
vs
/verbosity:minimal
causes a longer build log for the minimal! It appears diagnostic is hiding the details inside of a special task, which is part of Teamcity and not me;
[16:24:05]: Overriding target "SatelliteDllsProjectOutputGroup" in project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" with target "SatelliteDllsProjectOutputGroup" from project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets".
I am struggling with this because the Teamcity-generated build output log is so nice to have as a TreeView. That works with the SLN build but using any bat file cannot produce log file with the pretty (xml, presumably) tree-format.
If you have further ideas I will love to hear them, and thank you for your edits! :)
I have to build a .Net application that consumes a bunch of web service. This web service runs under weblogic. The WSDL of the web services mention a XSD file that describes the types.
When I try to add a "Service reference" with VS studio, I have some errors :
Warning 1 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: Schema with target namespace 'http://mycustomer/ws/types' could not be found.
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://mycustomer/ws/wsdl']/wsdl:portType[#name='lbWebPT'] C:\Projects\mycustomerproject\Service References\ClientService\Reference.svcmap
X3 for the portType, Binding and port elements of the wsdl file.
I was guessing this was because of the missing types defined in the xsd file. To workaround this error, and also to avoid duplicate code, I run the following command on my xsd file (in a pre-build event command line) :
"%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\bin\xsd.exe" "$(ProjectDir)xsdofmycustomer.xsd" /namespace:"MyCustomer.WebServices.Types" /c /o:"$(ProjectDir)."
this command successfully produces a code file with the types and with the correct namespace defined in the XmlRootAttribute.
this code has been put a dedicated VS project. The project where I'm trying to reference the service reference this project. However, the error is still occurring.
What can I do to solve my problem ?
PS: I was able to partially solve my problem using svcutil.exe pathtowsdl pathtoxsd, but I'd like to be able to maintain the reference in VS for ease of use.
thx
I'm not a fan of using project Service References because of the cruft the proxy generator inserts by default. But, if you really want to use Service References for your project then you need to merge the contents of the wsdl & xsd files into a single file. The Service Reference UI assumes all the data it needs to generate the proxy is in the file you give it. SvcUtil is more flexible as you found out. You should able to replace the wsdl:import element with a wsdl:types element that contains the xsd file contents (without the xml directive of course). Next, you enter the path to the file in the address textbox of the Add Service Reference dialog and you should be good to go with Visual Studio catered proxy goodness.
I have a Visual Studio 2010 solution that is set to build in Debug x86. Visual Studio therefore sets the output path to \bin\x86\Debug, which seems logical enough.
The solution contains about 50 projects; the start-up project is a WCF project.
When I do a build, I would expect all output dlls to go to \bin\x86\Debug, as that is what is set in the project settings. But weirdly, I see dlls being created in bin\x86\Debug and in \bin. Why would Visual Studio put any dll in \bin if the output path is not set to that directory? It seems that all dlls go to \bin\x86\Debug, and all dlls except for the start-up project go into \bin. Any idea why it would do that? (We have other solutions that don't use WCF, and they don't have this problem.)
The other annoyance is if I run the service from Visual Studio and then try to access my service in a web browser, by going to http://localhost:1240/MyService.svc, it doesn't work, because the start-up project dll is missing from /bin. I therefore have to manually copy this one dll from \bin\x86\Debug to \bin, so that all dlls are found and the service runs normally. (We could of course add a custom post-build step that does the copy, but you'd think there'd be a better way!)
To those of you working on WCF projects, do you leave the output path at \bin\x86\Debug? (Perhaps there is a way to configure the service, eg in the web.config or .svc file, so that it knows the binaries are in \bin\x86\Debug instead of \bin?) Or do you change the output path to \bin so that you can run your service straight from Visual Studio?
If you open the property page of you WCF Hosting project and goto tab Build, under the Output section of this tag there is a textbox that contains the location of the output binaries.
For a WCF project the binaries should go to bin directory irrespective of the build type (suc as Debug, Release). Make sure this value has been configured correctly.
The value needs to be configured for each build type\configuration.
If you need, for whatever reason, different outputs from different build configurations in different folders you could specify them like you did first and use a post build event command line that copies from your specified output folder to bin.
Like:
- untested code -
COPY/Y "$(OutDir)\*.*" "$(SolutionDir)$(ProjectName)\bin\"
- untested code -