如何提高C#开发server程序的效率# Programming - 葵花宝典
c*8
1 楼
在北京签证。
DS160确认页还需要手写姓名，地址吗？是不是签过后还要留个地址来寄签证？
听说要去某个邮局办理，是这样吗？谢谢！
DS160确认页还需要手写姓名，地址吗？是不是签过后还要留个地址来寄签证？
听说要去某个邮局办理，是这样吗？谢谢！
d*6
2 楼
我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
以把我招过去。
到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
server的程序。现在在这基础上开始功能扩展。
问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
完要先停止service，compile，copy，restart service……debug改一个小错误都要几
分钟，实在太累人了。以前用Groovy/Grails+InteliJ的时候，直接点击debug按钮就启
动一个temporary的local server，上面改动什么东西都可以auto-compile，几秒钟以
后就能测试了。
C#能做到吗，不行的话可咋整啊？
问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
以把我招过去。
到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
server的程序。现在在这基础上开始功能扩展。
问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
完要先停止service，compile，copy，restart service……debug改一个小错误都要几
分钟，实在太累人了。以前用Groovy/Grails+InteliJ的时候，直接点击debug按钮就启
动一个temporary的local server，上面改动什么东西都可以auto-compile，几秒钟以
后就能测试了。
C#能做到吗，不行的话可咋整啊？
N*n
3 楼
这个东西有得有失。Managed code需要COMPILE所以花时间，但是经过
STATIC TYPE COMPILE后能查出很多低级错误，花这点时间值得。
STATIC TYPE COMPILE后能查出很多低级错误，花这点时间值得。
z*3
4 楼
看了看，觉得还是xcode/apple好
也觉得还是java好，几分钟调试一次，这种搞法，开发太慢了
也觉得还是java好，几分钟调试一次，这种搞法，开发太慢了
z*3
5 楼
人家招你进去，应该是指望你带给他们一些东西
比如groovy那些，为啥不直接告诉他们你以前是怎么搞的？
然后演示一遍给他们看？c#语法要换成groovy并不难
比如groovy那些，为啥不直接告诉他们你以前是怎么搞的？
然后演示一遍给他们看？c#语法要换成groovy并不难
g*g
6 楼
就算Java也有JRebel存在，C#太落伍了。
n*w
7 楼
不能在local上test run吗？按一下f5等几秒。
看到在server马上要出来下一版本不用自己编译，源文件放上去roslyn会自动处理。
VS
【在 d**********6 的大作中提到】
: 我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
: 问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
: 新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
: 以把我招过去。
: 到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
: server的程序。现在在这基础上开始功能扩展。
: 问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
: 写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
: 后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
: 完要先停止service，compile，copy，restart service……debug改一个小错误都要几
看到在server马上要出来下一版本不用自己编译，源文件放上去roslyn会自动处理。
VS
【在 d**********6 的大作中提到】
: 我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
: 问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
: 新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
: 以把我招过去。
: 到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
: server的程序。现在在这基础上开始功能扩展。
: 问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
: 写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
: 后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
: 完要先停止service，compile，copy，restart service……debug改一个小错误都要几
N*n
8 楼
VS自带IIS模拟，只要不是复杂的系统在VS理F5就可以调试了。不用ATTACH
IIS之后再DEBUG。
【在 n*w 的大作中提到】
: 不能在local上test run吗？按一下f5等几秒。
: 看到在server马上要出来下一版本不用自己编译，源文件放上去roslyn会自动处理。
:
: VS
x*n
9 楼
Debug的时候用I is express，直接在local机器上运行。visual studio 的debugger自
动就attach了。修改code再编译就几秒钟的事。在ide的集成上，idea虽然很不错，
visual studio还是更强大
动就attach了。修改code再编译就几秒钟的事。在ide的集成上，idea虽然很不错，
visual studio还是更强大
w*7
10 楼
在dev local machine 也可以装IIS,可以直接debug. Remote debug是远端sever上没有
VS,然后attach process.
我们都是在local 编译,调试基本没有问题,才会push到QA或production sever,有问题
remote debug.
VS应该是最好用的IDE,软软正在推跨平台的VS,如果真能打通所有OS,也是码农们的福气
.
VS,然后attach process.
我们都是在local 编译,调试基本没有问题,才会push到QA或production sever,有问题
remote debug.
VS应该是最好用的IDE,软软正在推跨平台的VS,如果真能打通所有OS,也是码农们的福气
.
b*o
11 楼
在local上run IIS很简单啊，每次有新的改动在VS上按一下F6，然后到browser上按一
下F5就可以看到刷新的page。要是想到server上test也是简单。按ALT+;+P就可以把你
这个page publish到server上，然后上browser上F5一下就可以了。这些都不需要
session重来。要是整个publish到server上，publish要花点时间的。
下F5就可以看到刷新的page。要是想到server上test也是简单。按ALT+;+P就可以把你
这个page publish到server上，然后上browser上F5一下就可以了。这些都不需要
session重来。要是整个publish到server上，publish要花点时间的。
d*6
12 楼
这个不大可能会实现了。这家公司已经深深的跟MS家绑定了，所有的东西从OS，app，
service以及员工的skill set全是MS家的
前面有网友说的也对，有得有失。我自己用的经验，InteliJ的compile和debug时间很
快，但edit的响应速度就很慢，要scroll到某一行可能需要等十几秒，一样让人很抓狂。
我相信MS家是有办法解决这个开发效率的问题的，只不过我不熟悉怎么搞。
【在 z*******3 的大作中提到】
: 人家招你进去，应该是指望你带给他们一些东西
: 比如groovy那些，为啥不直接告诉他们你以前是怎么搞的？
: 然后演示一遍给他们看？c#语法要换成groovy并不难
service以及员工的skill set全是MS家的
前面有网友说的也对，有得有失。我自己用的经验，InteliJ的compile和debug时间很
快，但edit的响应速度就很慢，要scroll到某一行可能需要等十几秒，一样让人很抓狂。
我相信MS家是有办法解决这个开发效率的问题的，只不过我不熟悉怎么搞。
【在 z*******3 的大作中提到】
: 人家招你进去，应该是指望你带给他们一些东西
: 比如groovy那些，为啥不直接告诉他们你以前是怎么搞的？
: 然后演示一遍给他们看？c#语法要换成groovy并不难
d*6
13 楼
好像是一个通用的service，好几个组的人都用它，可能会挺复杂。
目前看来我们不负责这个service的开发和修改，只需要调用
【在 N********n 的大作中提到】
:
: VS自带IIS模拟，只要不是复杂的系统在VS理F5就可以调试了。不用ATTACH
: IIS之后再DEBUG。
目前看来我们不负责这个service的开发和修改，只需要调用
【在 N********n 的大作中提到】
:
: VS自带IIS模拟，只要不是复杂的系统在VS理F5就可以调试了。不用ATTACH
: IIS之后再DEBUG。
p*a
14 楼
感觉你们公司的人太弱。这明明是本地就可以用iis express debug的，和visual
studio是无缝整合的。另外就算不用visual studio publish，写个power shell
script把编译和部署自动化也就几分钟的事。
VS
【在 d**********6 的大作中提到】
: 我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
: 问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
: 新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
: 以把我招过去。
: 到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
: server的程序。现在在这基础上开始功能扩展。
: 问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
: 写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
: 后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
: 完要先停止service，compile，copy，restart service……debug改一个小错误都要几
studio是无缝整合的。另外就算不用visual studio publish，写个power shell
script把编译和部署自动化也就几分钟的事。
VS
【在 d**********6 的大作中提到】
: 我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
: 问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
: 新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
: 以把我招过去。
: 到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
: server的程序。现在在这基础上开始功能扩展。
: 问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
: 写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
: 后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
: 完要先停止service，compile，copy，restart service……debug改一个小错误都要几
k*n
15 楼
是楼主快猛糙习惯了，从不适应其他SDLC吧。
不管java，c#都要build然后deploy,
现在连node.js都用上build了。
简单的说，
首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
然后你checkin TFS 或其他的source control， 然后continue Integration自动build
与deploy到服务器上。
服务器应该有dev,qa,uat ，Prod等，
你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
稍正规点的软件公司都这样的。
不管java，c#都要build然后deploy,
现在连node.js都用上build了。
简单的说，
首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
然后你checkin TFS 或其他的source control， 然后continue Integration自动build
与deploy到服务器上。
服务器应该有dev,qa,uat ，Prod等，
你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
稍正规点的软件公司都这样的。
d*6
16 楼
应该是因为我们组的人不负责开发那部分，所以不大懂，不过谢谢指点
【在 p*a 的大作中提到】
: 感觉你们公司的人太弱。这明明是本地就可以用iis express debug的，和visual
: studio是无缝整合的。另外就算不用visual studio publish，写个power shell
: script把编译和部署自动化也就几分钟的事。
:
: VS
【在 p*a 的大作中提到】
: 感觉你们公司的人太弱。这明明是本地就可以用iis express debug的，和visual
: studio是无缝整合的。另外就算不用visual studio publish，写个power shell
: script把编译和部署自动化也就几分钟的事。
:
: VS
d*e
17 楼
一般语言开发都有watch, deploy。 IIS应该也有。github上找找。
没有自己写个也应该很快。
【在 d**********6 的大作中提到】
: 应该是因为我们组的人不负责开发那部分，所以不大懂，不过谢谢指点
没有自己写个也应该很快。
【在 d**********6 的大作中提到】
: 应该是因为我们组的人不负责开发那部分，所以不大懂，不过谢谢指点
n*n
18 楼
这么慢的响应速度，可以扔掉了。
狂。
【在 d**********6 的大作中提到】
: 这个不大可能会实现了。这家公司已经深深的跟MS家绑定了，所有的东西从OS，app，
: service以及员工的skill set全是MS家的
: 前面有网友说的也对，有得有失。我自己用的经验，InteliJ的compile和debug时间很
: 快，但edit的响应速度就很慢，要scroll到某一行可能需要等十几秒，一样让人很抓狂。
: 我相信MS家是有办法解决这个开发效率的问题的，只不过我不熟悉怎么搞。
狂。
【在 d**********6 的大作中提到】
: 这个不大可能会实现了。这家公司已经深深的跟MS家绑定了，所有的东西从OS，app，
: service以及员工的skill set全是MS家的
: 前面有网友说的也对，有得有失。我自己用的经验，InteliJ的compile和debug时间很
: 快，但edit的响应速度就很慢，要scroll到某一行可能需要等十几秒，一样让人很抓狂。
: 我相信MS家是有办法解决这个开发效率的问题的，只不过我不熟悉怎么搞。
c*e
19 楼
我门公司没有qa,用jenkins来管理c# project,真心没有publish来得直接方便。
build
【在 k**n 的大作中提到】
: 是楼主快猛糙习惯了，从不适应其他SDLC吧。
: 不管java，c#都要build然后deploy,
: 现在连node.js都用上build了。
: 简单的说，
: 首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
: 然后你checkin TFS 或其他的source control， 然后continue Integration自动build
: 与deploy到服务器上。
: 服务器应该有dev,qa,uat ，Prod等，
: 你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
: 稍正规点的软件公司都这样的。
build
【在 k**n 的大作中提到】
: 是楼主快猛糙习惯了，从不适应其他SDLC吧。
: 不管java，c#都要build然后deploy,
: 现在连node.js都用上build了。
: 简单的说，
: 首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
: 然后你checkin TFS 或其他的source control， 然后continue Integration自动build
: 与deploy到服务器上。
: 服务器应该有dev,qa,uat ，Prod等，
: 你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
: 稍正规点的软件公司都这样的。
d*6
20 楼
你说的这套正正是我们公司的模式
我困惑的是api的development，他们怎么完成在本机fix bug。因为我们组在用他们的
sln的时候是要attach才能debug的。不过我的担心可能多余，他们只是可能是他们没有
传授我们怎么做而已。
build
【在 k**n 的大作中提到】
: 是楼主快猛糙习惯了，从不适应其他SDLC吧。
: 不管java，c#都要build然后deploy,
: 现在连node.js都用上build了。
: 简单的说，
: 首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
: 然后你checkin TFS 或其他的source control， 然后continue Integration自动build
: 与deploy到服务器上。
: 服务器应该有dev,qa,uat ，Prod等，
: 你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
: 稍正规点的软件公司都这样的。
我困惑的是api的development，他们怎么完成在本机fix bug。因为我们组在用他们的
sln的时候是要attach才能debug的。不过我的担心可能多余，他们只是可能是他们没有
传授我们怎么做而已。
build
【在 k**n 的大作中提到】
: 是楼主快猛糙习惯了，从不适应其他SDLC吧。
: 不管java，c#都要build然后deploy,
: 现在连node.js都用上build了。
: 简单的说，
: 首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
: 然后你checkin TFS 或其他的source control， 然后continue Integration自动build
: 与deploy到服务器上。
: 服务器应该有dev,qa,uat ，Prod等，
: 你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
: 稍正规点的软件公司都这样的。
k*n
21 楼
你的api好像是WCF吧。
在VS里就能运行啊。
如果是不同sln，
开两个VS， 一个client,一个API，同时debug。
【在 d**********6 的大作中提到】
: 你说的这套正正是我们公司的模式
: 我困惑的是api的development，他们怎么完成在本机fix bug。因为我们组在用他们的
: sln的时候是要attach才能debug的。不过我的担心可能多余，他们只是可能是他们没有
: 传授我们怎么做而已。
:
: build
在VS里就能运行啊。
如果是不同sln，
开两个VS， 一个client,一个API，同时debug。
【在 d**********6 的大作中提到】
: 你说的这套正正是我们公司的模式
: 我困惑的是api的development，他们怎么完成在本机fix bug。因为我们组在用他们的
: sln的时候是要attach才能debug的。不过我的担心可能多余，他们只是可能是他们没有
: 传授我们怎么做而已。
:
: build
相关阅读
推荐一个Clojure Web微框架谈一谈计算机程序里那些边边角角的skillsnode现在还行么？用的地放多不多？怎么恢复损坏的7-zip archive文件？scala的future和java7的基本原理是一样的么？网站前端都是用javascript和html写的吗 ？请问Python可以开发独立运行的应用程序吗？科班不科班早都过时了go做得越来越好了啊，已经有人开始用go实现jvm了写go有 脱裤子放屁的感觉 太底层搞不懂为什么大牛说Hbase不如C*?一部关于图灵的电影。Oculus有人关注吗vert.x v3发布了哪个大牛能用1０－2０句话讲讲paxos？Go 1.5 will be able to build iOS appsnetflix down?问一下在flg的，你们写java代码 要求写这陀注釋 javadoc什么的(转载)go channel和clojure core.async哪个好leap second！